OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Streaming XML (WAS: More on taming SAX (was Re: [xml-dev]

[ Lists Home | Date Index | Thread Index ]

On Thu, 30 Dec 2004 13:05:37 -0700, Uche Ogbuji
<Uche.Ogbuji@fourthought.com> wrote:
>  I'm sure I can win a "productivity" bake-off using
> available Python/XML tools any day against any XQuery machine.  I can
> say the same for most of my colleagues.

I love that idea .   Iit would be fun and instructive to see a bakeoff
with Erik Meijer in one corner with C-Omega, Uche in another corner
with Amara, Michael Kay in another corner with XSLT, and an XQuery
zealot-to-be-named-later in another corner, working away at a few
randomly chosen XML problems. :-)  Anyone want to organize a physical
or virtual version of that?  (Apologies to the people named, I'm
personifying the tools for rhetorical purposes not making a serious

The trouble is, I'll bet that the results would depend on the problems
chosen more than the tool used to build the solution -- There are
plenty of problems that C-Omega could solve in a few lines that XSLT
would bog down on even in the hands of a master, and vice versa. I
wouldn't be surprised at all if Python or XQuery were the best overal
with some fair and balanced distribution of problems, but that would
be meaningless to people who spend most of their lives with documents
and love XSLT, or spend their lives with straightforward schema-valid
data and can exploit the kinds of things that  C-Omega does at compile

Another problem is that there are at least two target audiences here
-- the people who learn and build tools for their own use, and those
who build tools for ordinary mortals to use.  The question in my mind
is whether the the winner of a bakeoff among XML ubergeeks would
predict the winner of a bakeoff among ordinary mortals with, say, a
week's training on the tool of choice?  That's a contest I would
REALLY like to see!

Sigh, yet another problem is the short-run vs long-run issue:  In the
long run we can expect with some confidence that the "declare what the
answer looks like and let the tool build the code" approach will work
best, but I doubt very much if any existing tools can do that.  On my
better days, I can see the point that Dana alluded to  that 
short-term optimization keeps the state of the art from advancing to
meet the full potential of the more declarative approaches.  Still, in
the long run we are all dead, and our careers will be dead much sooner
if we don't solve real customer problems in a reasonable timeframe!


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS