Lists Home |
Date Index |
At 10:54 AM 1/3/2002 -0700, Champion, Mike wrote:
> > From: Jonathan Robie [mailto:email@example.com]
> > Sent: Thursday, January 03, 2002 12:03 PM
> > Subject: Re: [xml-dev] The use of XML syntax in XML Query
> > >I think XQueryX
> > >could be redone in a more user-friendly form if that were desired.
> > But doing this would require major new work, and would set back the
> > schedule for XQuery 1.0 significantly. Especially since the resulting
> > syntax would be syntactically similar to XSLT, but would have to be
> > different because of the optimizability and type-safety goals
> > of XQuery.
>The schedule and the sorting out of the relationship between XQuery and XSLT
>are essentially organizational objectives that are more or less irrelevant
>to the larger community of XML users.
I disagree. When I speak on XQuery, people say they want XQuery now, not in
several years. Products that implement XQuery will be released this year,
and if the standard is not done this year, then the implementations done by
the biggest vendor will become the defacto standard. Do you really want the
XQuery standard to be released two years after Microsoft's implementation
hits the market? Since Software AG is implementing XQuery, don't we want to
be implementing something that conforms to an existing standard?
I do not believe that there is a real need to change XQuery's syntax to be
an XML-based syntax, the cost of doing so would be high, and there would be
a very real danger of bogging down the XQuery effort entirely. David and
Elliott both seem to feel that the computed element constructor syntax can
be used for their purposes.
The XQuery WG was chartered in 1999. It really does need to be able to
complete a 1.0 specification at some point. Members of the Working Group,
whose companies are contributing their time to the effort, did not sign up
for a project of unlimited duration.
>I [personally] would urge the XSLT/XQuery groups to:
>- Make sure that XPath 2.0 is as "clean" as possible, with features mainly
>used by XQuery or XSLT kept in the appropriate layers. This may be stating
>- Make the release of XPath 2.0 the highest priority; there is an immediate
>need for the additional features that it offers over XPath 1.0 in the XML
Most of these features came from XQuery, which adds very few new features
to XPath 2.0. XPath 2.0 and XQuery 1.0 are largely the same language. I
don't think it makes much sense to have these two languages be on different
I think the XML database world needs a single query language that can be
used without extra layers of DOM, SAX, Java, or XSLT to do everyday tasks.
And I think that the few features of XQuery that have not been taken into
XPath 2.0, such as function definitions and element constructors, are
extremely useful for everyday tasks.
>- Consider an XUpdate or whatever on top of XPath 2.0 as a the next highest
>priority, split it out from XQuery if that helps get it out faster.
>Alternatively, graciously cooperate with some non-W3C activity to define an
>XUpdate language cleanly layered on XPath 2.0 if the W3C does not have the
>bandwidth to pursue it.
Update requires element constructors.
Element constructors are one of the main differences between XQuery and
>- Let the others "cook" for as long as it takes to get them right. XPath
>2.0 and XSLT 1.0 can "hold down the fort" for a year or two, so don't use
>the argument that "such and such a proposal will delay XQuery!" as a reason
>not to explore the numerous suggestions that you are getting from the user
The XML Query WG was chartered in 1999.
What exactly are you asking us to get right? I think that you are
responding to a thread on our syntax for element constructors, and
specifically to my suggestion that we should not use native XML syntax to
replace the keywords of XQuery. Is this worth spending one or two years on?
>For example, this thread on XML-DEV has pointed to some
>potential problems in the "half XML, half non-XML" syntax of the
>element/attribute constructors that need to be carefully considered and
I don't think that will take one or two years, or that it needs to endanger
the delivery schedule for XQuery.