xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james_strac...@yahoo.co.uk>
Subject Re: [Announce] CyberNeko Tools for XNI 2002.06.18 Available
Date Thu, 20 Jun 2002 12:50:03 GMT
From: "Andy Clark" <andyc@apache.org>
> James Strachan wrote:
> > One question though; your Pipeline processor looks to be based on the
W3C
> > DOM (at least from the documentation, I've not surfed the code yet). Did
you
> > consider making a SAX or XNI based pipeline engine? If so what were the
> > reasons for having a DOM based pipeline?
>
> Yeah, I knew people would ask about that. I expect
> documents are going to be used multiple times so I
> figured it would be easiest to base the system on a
> tree API.

OK.

> And since the DOM is the standard tree
> API, it was the natural choice. (I know you would
> disagree and prefer to use DOM4J, though. :)

of course ;-)

Actually Jelly uses Jaxen for its XPath stuff so it can work with all 4
DOM-ish APIs, W3C DOM, dom4j, EXML and JDOM.


> Depending on what I need to do with the tool, I may
> end up adding additional ways to pass information
> from stage to stage. Adding SAX would be a natural
> choice, of course. However, performance is not one
> of my major priorities and adding other APIs would
> just increase the size of the code which IS one of
> my major priorities. Right now the Jar is 25K.

Agreed.

> > Incidentally I'm working on a Java and XML based processing engine
called
> > Jelly...
>
>  From what I can tell from the docs, it looks quite
> impressive. I'll definitely look into it more when
> I get a chance. However, it looks a lot bigger than
> what I need to do. The Jelly jar is 122K and it has
> a long line of requirements. (Excluding the XML
> parser and XSLT processor, what is the total size
> of required Jar files to run a typical Jelly
> script?)

You're right, I think Jelly is always going to be quite a bit bigger than
your pipeline tools. Though I do think your pipeline stuff would work very
nicely with Jelly if folks wanted more complex or powerful kinds of
pipelines like to mix some DOM-based XML pipeline processors with working
with beans, web services or SQL or whatnot.

Incidentally one of the reasons for the current Jelly jar being so large and
having so many dependencies is a current limitation of the Maven build
system. Jelly is really quite modular - the core is fairly small, then
different expression languages and tag libraries can be plugged in based on
what the user needs. Right now the whole thing is built in one bundle which
makes Jelly and its dependencies look bigger than it really is. Mostly
Jelly's core just depends on an XML parser and a few small jars from Jakarta
Commons (beanutils, collecitons, logging, jexl). Its other tag libraries
that bring in new dependencies.


> > representation for using Cybernecko processors, but it means we can then
mix
> > and match other tag libraries into the script too; like iterating and
> > conditional branching using various expression languages (Jexl, XPath,
> > Beanshell, JavaScript etc), iterating over files using Ant's
<fileset>'s,
> > executing Ant tasks inside the script, invoking SOAP services, using tag
> > macros, performing SQL or working with beans in a Velocity way etc.
>
> Cool.

BTW it wasn't my intention to suggest Jelly was in any way competitive
technology, more that Jelly could be an alternative runtime engine for your
pipeline processors; that if more power and complexity is required (such as
working with beans or web services) then Jelly + CyberNeko could well be
kinda cool stuff.


> > Thoughts? (I hope some of this made some sense ;-)
>
> I'll have to digest it all first. :)

:-)

And me of your pipeline stuff too ;-)

James


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org


Mime
View raw message