RE: [xml-dev] Anyone wanna speculate about what this means?

["Dare Obasanjo" <dareo@microsoft.com>]

Answer #1: http://edocs.bea.com/workshop/docs70/help/guide/xmlmap/conHandlingXMLWithECMAScriptExtensions.html 
 
Answer #2: 
A couple of us feel that XQuery will some of the problems with XSLT that have prevented it from becoming the lingua franca for processing XML by the average XML developer. XSLT's unnecessarily verbose syntax, limited set of useful builtin functions & operators and unfamiliar programming model (why is an xsl:variable called a variable if it doesn't vary?) have always made it seem inaccessible to many users who would otherwise benefit from it. XQuery fixes these issues which makes it more approachable to the thousands of developers who have to process XML data and have thus far limited themselves to object <->XML technologies , DOM or streaming APIs because they couldn't grok XSLT. 
 
XQuery is hot. 

________________________________

From: Mike Champion [mailto:mc@xegesis.org]
Sent: Sun 2/16/2003 5:29 PM
To: XML Dev
Subject: [xml-dev] Anyone wanna speculate about what this means?



In
http://www.fawcette.com/xmlmag/2003_02/magazine/columns/endtag/default.asp
Adam Bosworth says:

"It is the thesis of this series of articles that [DOM/JDOM,
SAX/databinding, and XSLT] are only rarely suitable for either waypoint
[lossless transformation] or endpoint [lossy data extraction] processing.
As I wrote in the prior article, they place an intolerable burden on the
developer. Two exciting new technologies, extensions to JavaScript for
native processing of XML (coming up through the aegis of ECMAScript) and
XML Query (from the W3C), can vastly improve performance and productivity
for this sort of programming. "

Two questions:

- Is there anything publicly available on the "extensions to JavaScript for
native processing of XML"?  I haven't heard of it, and Googleing didn't
turn up anything useful.

- Anyone want to speculate on why  one might think that XQuery will be
vastly better than these other technologies for XML transformations, lossy
or otherwise?  Technically, they are all more or less equivalent (assuming
one has an XPath library to find patterns in the XML).  As far as
productivity is concerned, I would guess that it depends ... some people
are productive with procedural code and a generic Infoset-ish data model,
some are productive with building a customized object model from the XML
tokens and manipulating it, and some are comfortable with XSLT's
declarative template/transformation model.  XQuery is one more approach
that some people are going to like (perhaps it will make XML streams look
like a good ol' database for SQL programmers), but I'm not aware of any
arguments that it will dramatically improve productivity or performance.

Thoughts, anyone?  Or are we just being setup for a marketing pitch?

--
Mike Champion


-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>