commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Madoni <>
Subject RE: [Jelly] Executable XML vs. Rich Configuration
Date Wed, 11 May 2005 17:42:30 GMT
Thanks for your reply, Paul. While I have several criticisms, my remarks
need to be received in the context of my appreciation for Jelly. I have far
more good than bad to say about it; but like most people, it's a lot easier
for me to talk about the bad. :)

I agree that "rich configuration" sells Jelly short ("intelligent
configuration" or "active configuration" might come a little closer, but
still wouldn't do it complete justice); but when it comes to positioning, I
would argue that the issue isn't whether you sell something short as much as
it is clearly demonstrating its usefulness.

Because of its XML nature, the solved problem that immediately connects with
Jelly would relate to configuration, storage, or perhaps page mark-up
processing (a la Cocoon)--you know: XML-ly things. 

Perhaps a better term that isn't as restrictive as "Rich Configuration" or
as strange as "Executable XML" might be "Active XML Processing", or
something like that. Such a term doesn't imply that you'll use it for
programming, and instead suggests that it's useful for what you already use
XML for, with Jelly adding a valuable "active" dimension to XML rather than
just thinking of an XML document as a data container or template.

I should also mention that the name Jelly may also be a liability. I know
we're all geeks and we name things after pets or food or whatever makes for
great lore; but for Jelly to grow up and be noticed, it needs a more
meaningful name.

I'd actually maybe like to help with the two big weaknesses I found in
Jelly: sparse documentation and script error handling. I can't do that on my
client's time, but feel free to e-mail me at to discuss
it on my own time.

-----Original Message-----
From: Paul Libbrecht [] 
Sent: Wednesday, May 11, 2005 2:30 AM
To: Jakarta Commons Users List
Subject: Re: [Jelly] Executable XML vs. Rich Configuration


This comes up to the point to re-consider the marketing of Jelly as we 
all wish to cut a release 1.0 soon!
I agree "executable XML" may suck but I think "rich configuration" is 
also quite "old fashioned" and is not that appropriate since there 
still is a notion of execution (or processing or pipeline).

Can you be more precise with the rants you've found about jelly ? (e.g. 
we could make a page "jelly sucks" with blog-like references and 

The best sub-title I found thus far was "mix-and-match" that's posted 
in one of the documentation pages.

We should brainstorm on this, I think.
Please bring more ideas about sub-titles or qualifiers for Jelly !


Le 11 mai 05, à 00:02, Dan Madoni a écrit :

> Having just completed a project using Jelly as a script execution 
> engine, it
> occurred to me that the perplexity I was initially met with regarding 
> Jelly
> ("executable XML? huh?") was displaced by appreciation for how 
> valuable it
> can be.
> As I began working on the project, I had a home-grown solution in mind 
> for
> the component that Jelly is now used in place of. The home-grown 
> component
> wasn't "executable XML", but it was very complex XML-based 
> configuration,
> and a cohort suggested that I look at Jelly after having perused my 
> design
> documentation.
> At first, I didn't exactly get it--why would I want to "execute" XML? 
> After
> thinking about it in the context of the project, it began to make a 
> great
> deal of sense for the specific purpose I had in mind: Jelly is ideal 
> for
> "rich configuration", where configuration data alone may be 
> insufficient or
> too cumbersome, and some sort of "intelligent" configuration is 
> needed, even
> to the point where the configuration data actually interacts 
> manipulatively
> with the application.
> I don't know if this is what Jelly's creator(s) had in mind upon 
> embarking
> on the project. Actually, I get the impression someone was caught up 
> in the
> same frenzy that compels people to try to solve every freaking problem 
> with
> XML, and just thought "It would be cool to program with XML. Yeah, 
> that's
> cool." In any case, I think I'm the rule and not the exception when I 
> say
> that the idea of "executable XML" sounds like a solution in search of a
> problem. If my fellow developer hadn't already been familiar with 
> Jelly and
> put two and two together to suggest it as something I could use, I may 
> well
> have come across the Jelly home page some other way and assumed a 
> Squidward
> attitude ("oh puh-leeze").
> Other than what I believe to be a misplaced identity, the only other 
> nits I
> have are that the documentation leaves much to be desired and debugging
> Jelly scripts is awfully cumbersome when the script error raises a Java
> exception (perhaps script execution exception handling could have been 
> a bit
> better thought out).
> But I can't really complain. Jelly is fabulous, and was absolutely key 
> in
> making this application work as well as it does. It would probably 
> find more
> users and less scorn (I read some really harsh stuff while researching 
> it)
> if it were simply repositioned a bit. The whole "executable XML" theme 
> is
> cute and might make an interesting discussion at a nerd convention, 
> but I
> would guess that there are far more developers who need to tackle 
> complex
> configuration problems and who will readily understand the meaning of 
> "rich
> configuration" or "intelligent configuration" than there are 
> developers who
> regard Utopia as being able to code in XML.

To unsubscribe, e-mail:
For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message