RE: The use of XML syntax in XML Query
> -----Original Message----- > From: Champion, Mike [mailto:Mike.Champion@S...] > Sent: Thursday, January 03, 2002 2:37 PM > To: www-xml-query-comments@w...; xml-dev@l... > Subject: RE: The use of XML syntax in XML Query > > What exactly are you asking us to get right? > I have no particular opinion on the issues being > pushed back, but I think they deserve more thorough consideration than "we can't > think about alternatives because we gotta ship". After a little chat with Jonathan, it has become clear that I both underestimated the complexities here and somewhat misrepresented the "we gotta ship" position. The XML-DEV list seems to have generated a fair amount of pushback on five issues: - Strong typing as a requirement in XQuery - The role of XQuery vs XSLT as a way of displaying query results - The use of quasi-XML syntax in the XQuery element/attribute constructors - The XQueryX pure XML syntax for all of XQuery - Updates Here's my current understanding of these issues: Strong typing - There is a real-world use case for ensuring that queries return schema-valid results, for example ensuring that they can be displayed in valid XHTML. (Whether anyone outside the W3C cares about schema-valid XHTML is another matter, but it is a "real world" example that I'm sure has counterparts with more data-oriented schemas in the REAL real world). Doing this is a hard, but solveable problem, and solving it requires that XPath 2.0 and XQuery be designed as a unit, even if they are layered once everything is done. Thus, "declaring victory" on XPath 2.0 without solving this problem is essentially declaring defeat on some matters near and dear to XQuery, since it is very unlikely that they could be solved in XQuery without changing XPath. XQuery vs XSLT - essentially the same matter: XSLT wasn't designed up front to solve the "schema valid queries" problem, so XQuery must have its own "constructor" syntax. Constructor syntax - It sounds like XQuery does not depend heavily on the constructor syntax; I mis-attributed the "we can't think about that because we gotta ship" response to the XQueryX pushback to the response to the constructor syntax pushback. I get the impression that this is open to discussion, e.g. the "curly brackets instead of tags" idea. XQueryX - Nobody is terribly enthusiastic about this one way or the other, so it could be delayed to XQuery 2.0 if there is not a compelling reason not to; if it has to be in 1.0, there is no bandwidth to consider more readable (XSLT-like?) syntaxes. Updates - This is impossible to address on top of XPath 2.0 alone without a constructor syntax, so updates must be an integral part of XQuery. [That's Jonathan's expert opinion; maybe those who've worked on XUpdate disagree?] So, it appears that this really is a barrel of snakes, not easily susceptible to a "divide and conquer" approach. I can sympathize with the perception that declaring victory on XPath 2.0 makes their problems all the harder. There's no way obvious way to add updates to XQuery 1.0 or seriously re-think the relationship between XSLT and XQuery without either a) pushing back the schedule significantly or b)giving up all hope of the strongly typed queries coming together without yet another start from scratch. So, [my personal analysis, flame away if you disagree] there isn't going to be an XQuery Recommendation that has joins, a strong type system for queries and results, and updates anytime soon. I would guess that the debate would be best served by: - informed arguments as to whether or not a strong type system for XQuery built on the W3C XSD is feasible given the state of the art and the maturity of XSD. - realistic assessments of the tradeoffs between an XQuery Recommendation without updates sooner and one with updates later - plausible alternatives ways to produce short-term interoperability guidelines for XML database vendors and applications developers while all this is cooking in the W3C Labs. Is there some quick 'n dirty hack of XPath 1.0 + a join syntax + an update syntax that could tide us over for a year or two, or would that create more long-term problems than short-term solutions?
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