[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: nostalgia (was RE: Ten new XQuery)
At 01:03 PM 5/10/2003 -0400, Mike Champion wrote: >- "misbegotten" and "poison" may be a bit strong, but the fact remains >that both XSDL and XQuery have been largely driven by the needs of the >RDBMS vendors and vendors of development tools for statically typed languages. Be careful here - from day one, we had a requirement to query merely-well-formed XML, XML governed by a DTD, or XML governed by a schema. The static type system of XQuery clearly has been designed to meet the needs of those doing data integration in environments that contain relational data. But much of the design of XQuery came directly from playing around with the Use Cases, trying to find a language that could solve them well. To me, the biggest differences between Quilt [1] and XQuery involve the addition of SequenceType, static typing, and a more solid understanding of the Data Model. And the type system and Data Model have been as much driven by the need to represent merely-well-formed XML and XML with irregular or document structures as it has by the need to represent relational data. >The "XML view of an RDBMS" or "XML serialization of an object" use cases >are definitely valid ones, but not ones that excites a lot of people here >who are using XML views of, uhh, XML. XQuery was designed as a native XML language. To borrow Adam Bosworth's example, suppose you need to calculate Price/Earning ratios from data like this: <stock> <name>Cindy's Snowshoes</name> <ticker>NASDAQ:RAKD</ticker> <price>20.00</price> <revenues>2.00</revenues> <expenses>1.00</expenses> </stock> With Java and the DOM you wind up doing things like this: Tree t = ParseXML("stock.xml"); PERatio = number(t.getmember("/stock/price")) /((number(t.getmember("/stock/revenues") - number(t.getmember("/stock/expenses")) With XQuery, you can work much closer to the logical structure of the underlying XML: let $stock := document('stock.xml')/stock return $stock/price div ($stock/revenue - $stock/expenses) The fact that XQuery operates at this level is a fundamental, important aspect of its design. That's what makes it an XML query language. The language is defined purely in terms of XML. >- Some of the confusion and *possibly* unfair assertions that XQuery is >inextricably bound up with the philosophy of static typing (e.g. >http://seanmcgrath.blogspot.com/2003_05_04_seanmcgrath_archive.html#200265755 >where Sean links to the XQuery magnum opus in the sentence "Sadly, those >who really, really like static typing have also penetrated the XML world >to terrible effect in recent times") come largely from the advocacy about >the benefits of static typing by XQuery WG members on this list and elsewhere. Static typing is an optional feature of XQuery. Sean seems to prefer dynamic typing to static typing. He doesn't give any real detail in the above Blog entry, so it's hard to know whether his interests would best be served by using an implementation of XQuery that does not support static typing or disabling static typing. >So, I think that much of what is *better* about this latest draft of >XQuery et al. than the early drafts is in fact due to the "megabytes of >mail traffic" on this list, the xsl list, etc. pushing back on the more >questionable decisions about to tightly bind these specs to XSDL and/or >the PSVI. They may not seem like valid concerns to someone working on XML >views of objects or databases, but they reflect the valid concerns of real >people. In other words, LOTS of valid issues have been brought up (and >addressed in a thoughtful manner by the various WGs). I suspect that >there are a lot more and once again urge people to review these drafts >with an open mind, but let's KEEP pushing to make them truly fit the needs >of the XML community. The Working Groups do read and think about specific technical comments made on our specs - if these comments are made to the public feedback list (<mailto:public-qt-comments@w...>public-qt-comments@w...) then a much larger percent of the Working Groups is likely to actually see them, but some of us do also read XML-dev, and substantive comments made here are also discussed. The Data Model, which is in Last Call, is particularly important right now - we have tried to design it so that we support XML Schema, but also merely-well-formed XML and XML governed by DTDs. We have also tried to keep it relatively simple. If people have time to review only one document, this is the one. Jonathan [1] http://www.almaden.ibm.com/cs/people/chamberlin/quilt.html
|
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
|