[
Lists Home |
Date Index |
Thread Index
]
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@w3.org>public-qt-comments@w3.org) 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
|
