[
Lists Home |
Date Index |
Thread Index
]
> -----Original Message-----
> From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com]
> Sent: Thursday, January 03, 2002 2:37 PM
> To: www-xml-query-comments@w3.org; xml-dev@lists.xml.org
> Subject: RE: [xml-dev] 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?
|
