Lists Home |
Date Index |
* Kevin Jones <email@example.com> [2004-12-27 15:46]:
> On Monday 27 December 2004 20:00, Daniela Florescu wrote:
> > Could you guys please try to clarify for me the answer to
> > the following question: instead hand coding steaming
> > applications using SAX, couldn't you write some XQuery code
> > (with external functions probably) to do the same thing ? Did
> > you try at least ? Did you try and fail ? If yes, why did it
> > fail ?
> Funny, I was just discussing why this might be with someone
> from work an hour ago. My perspective is not that valid,
> being an implementor more often than a user, but our
> conclusion was this is as much about practical issues than
> technical. The main problems being the relatively poor
> integration between the programming languages of choice and
> XQuery/XSLT and lack of interesting implementations in easy
> to use component form.
I got sucked into it a year ago, somehow, while writing a
document object model, one of the things it kicked out was a SAX
library that I kept reworking, and now I'm quite pleased with it.
It changed the way I looked at documents, after having spent a
long time writing XSLT.
For me, it is a yacc surrogate. If I have a repetitious problem,
like configurting Java object, I think of an XML grammar that
repeats the steps, and implement it as a stack-based automation
using my SAX Strategy library.
I've gotten pretty good at assembling a SAX engine quickly by
composing one using resuable strategies. Things like
serialization and document building I delegate to JDK 1.4.
In these cases, it doesn't buy me anything to have the whole
document in memory, since I'm either assembling some sort of
AST, or just responding to events, any state that is build up is
If I were to pull the XML into a DOM, id pretty much recurse
over the nodes anyway, visiting each one in turn.
I'm sure if I were proficent in JavaCC, I'd be cobbling togehter
little languages as frequently as SAX filters.
Alan Gutierrez - firstname.lastname@example.org