OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] The use of XML syntax in XML Query

[ Lists Home | Date Index | Thread Index ]

At 10:54 AM 1/3/2002 -0700, Champion, Mike wrote:

> > From: Jonathan Robie [mailto:jonathan.robie@softwareag.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
>the obvious.
>- 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
>database world.

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 
release schedules.

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 
XPath 2.0.

>- 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
>alternatives weighed.

I don't think that will take one or two years, or that it needs to endanger 
the delivery schedule for XQuery.



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS