[
Lists Home |
Date Index |
Thread Index
]
On Tue, 28 Dec 2004 12:22:25 -0800, Daniela Florescu <dflorescu@mac.com> wrote:
> My conclusion: please rely on good compilers, good optimizers
> and good runtimes instead of writing XML processors by hand if
> you don't *really* have to (and few people really have to).
> And trust the vendors/open source implementors that
> they will produce such good compilers, optimizers and runtimes when time comes.
That makes sense, and is obviously the direction that programming
languages have taken in the last 20-30 years. I'm old enough to
remember when many geeks didn't trust C compilers to do the right
thing and wrote lots of assembly code by hand. Fortunately those days
are past!
But are they past in the XML world? What are these "next versions of various
industrial strength products" and what will they do for the people in
this thread who are using SAX or a pull parser to handle large data
streams rather than simply trusting XQuery or XSLT implementations to
do the right thing? As a couple of people noted, it would be easier
to believe this if commercial RDBMS really did implement Codd's vision
of allowing people to work only at the logical and conceptual level
and not worry about those physical implementation details. I guess
they do for most typical user scenarios, but at least the last I
heard, people who really have to worry about performance/scalability
have to be deeply involved in details of normalization, indexing, and
query optimization.
I'm prepared to believe that XML users won't have to care about this
stuff someday ... but I haven't seen much evidence that "someday" is
anytime soon. Could you be just a bit more specific about which
products or technologies will handle which problems discussed in this
thread better than hand-coding to SAX or Pull APIs?
Or are we all saying the same thing, that typical users can rely on
XQuery/XSLT and *only* the geeks who get the hard problems have to
consider writing SAX code anymore? I have no quarrel with that, other
than the obvious fact that the subscribers to this list tend to be the
geeks who get called into to fight the performance fires. :-)
|