[
Lists Home |
Date Index |
Thread Index
]
* Oleg Tkachenko <oleg@tkachenko.com> [2004-12-28 05:40]:
> Michael Champion wrote:
>
> >I'm not sure how that will ever
> >change; for example, people are still fiddling with their SQL code and
> >table organizations to get optimal performance rather than simply
> >trusting the implementations. Why will that be different for
> >XPath/XQuery?
>
> I believe Daniela's point is that people shouldn't come up with
> home-brewed XML processing engines nowadays just as nobody's writing
> home-brewed database engines anymore. XML processing shouldn't be a
> matter of art, while it shouldn't perform poorly by default neither.
>
> Imagine a guy who only wants to rename some elements in an XML document.
> SAX filter/custom XmlReader is one way to go, 10-lines XSLT stylesheet
> is another one (and a better one as being declarative).
> The sad thing is that XSLT impementations currently aren't smart enough
> to realize that such XML transformation can be done in a streaming way,
> so XSLT way's perf will be definitely worse and XSLT will definitely be
> the one to blame.
I'm not one for nattering on listservs, so I can't tell when
horse is dead, please tell me if I should stop beating.
Part of this is a debate over declarative versus procedural
programming. Here one person has made an absolute statement,
that is backed up by millions in marketing dollars from various
RDBMS vendors (not a cynical statement, they make fine
products), in favor of a declarative expression of a task over
a procedureal expression. Daniela has compared XQuery and XSLT
to SQL, while SAX and STAX are assembler.
Except that, XSLT is a functional programming language, and
from what I can see of XQuery, it has a lot of looping. SQL is
a declaration of, well not my lexicon, a desired result set in
the terms of relational calculus.
Are XSLT and XQuery declarative?
There no direct conceptual mapping from XQuery to SQL. There is
no direct conceptual mapping from SAX and STAX to assembler.
SAX and STAX are not languages. They are application
programming interfaces.
In my world, Java application programming, I see the choices as
SAX, STAX, DOM4J, W3C DOM, or TRAX. I am being told to consider
TRAX my panecea.
Using TRAX immediately adds adds support issues, such as the
Xalan inconsistancy, a weak parser shipped with the JDK,
resource files, and additional langauges.
The idea that my problems are made simplier by implementing my
program as Java method bindings to an XSLT engine is absurd.
Now I've committed myself to a particular XSLT implementation,
TRAX is out the window.
Java, Python, Perl, XSLT, XQuery. Those are langauges.
They are all Turing complete. Any algorithm that can be
expressed in Java can be expressed in XSLT. If what I want to
express is the construction of a JMenuBar, using XSLT is going
to be a nightmare.
Here's what this sounds like to me:
"Any modern user interface an be expressed using XForms, XML +
CSS, and SVG, and binding behavior to the DOM Event Model."
"Therefore, people should abandon direct GDI, PalmOS API, Cocoa,
or GTK+ programming, abandon Swing, wxWindows, SWT, Qt, and
pour there energies into writing XForms, XML + CSS, and SVG
applications, because that will drive the development of
rendering engines."
"We simple need to commit to developing these rendering engines,
and all accept that the declarative UI will reign supreme,
from handhelds to computer animation."
"To worry about the performance of your UI is waste of effort.
The rendering engines will, eventually, know how to optimize
for any and all problems."
"Any anyone who wants to pick up a pen and scribble on the
device context in C is just a dinosaur."
That was meant to sound, ideal, yet rediculous, for the record.
Thinking harder about streaming libraries, expression of
streaming problems, and the needs of stream processing is a
good thing, because, as an concept in data, the stream is not
going to go away. It is not an ugliness. It is what data does
on its way from here to there. Perfectly natural.
Cheers.
--
Alan Gutierrez - alan@engrm.com
|
