Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Anyone wanna speculate about what this means?
 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@x...] Sent: Sun 2/16/2003 5:29 PM To: XML Dev Subject: 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> 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
