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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] RE: xquery v1.1 tracking xquery x was Re: [xml-dev] RE: Declarative programming requires a different mindset

Mike's pretty much got it right re: XQueryX, but I thought I might 
add my perspective.  Among other jobs, I'm the editor for the XQueryX 
1.1 document and the primary editor of the XQueryX 1.0 document.

First, as Mike implied, XQueryX 1.1 is to XQuery 1.1 what XQueryX 1.0 
was (is, actually) to XQuery 1.0.  That is, it's an XML syntax to 
represent the semantics of the same version of XQuery.

Second, in the same manner that the XML Query WG has striven to 
ensure the absolutely fewest incompatibilities possible between 
XQuery 1.1 and XQuery 1.0, it has striven to ensure the fewest 
possible incompatibilities between XQueryX 1.1 and XQueryX 1.0.  I'm 
reluctant to make absolute statements, but I believe that there are 
in fact *no* incompatibilities at the XML syntax level between 
XQueryX 1.1 and XQueryX 1.0.  What incompatibilities might exist 
would be purely in the semantic differences between the two versions 
of the XQuery language.

What one will see in XQueryX 1.1 is some areas where the XML syntax 
doesn't map to the human-readable syntax in precisely the same manner 
that XQueryX 1.0 syntax mapped to the XQuery 1.0 syntax.  This was 
done to eliminate possible syntax differences at the XQueryX 
level.  (No, that doesn't imply an incompatible difference in the 
XQuery 1.1 syntax, either, only a difference in the manner in which 
the grammar mappings were done.)

In fact, the XQuery grammar *has* been modeled in XML.  The grammar 
that you see printed/displayed in Appendix A of the XQuery (1.0 and 
1.1) specs is generated from XML sources; in fact, we've integrated 
the XPath, XQuery, Update, and Full Text grammars in those XML 
sources and each document generates its own grammar from the same 
sources.  But I don't know what you mean by "a shorthand version of 
XQuery".  If you're familiar with the XQueryX syntax, you'll know 
that the XQueryX expression of a given query requires several times 
as many characters (keystrokes, bytes, whatever measure you use) as 
the same query expressed in the human-readable syntax.  I wouldn't 
call that a "shorthand" ;^)

Hope this helps,

At 4/14/2010 02:00 PM, Michael Kay wrote:
> >
> > how much is the current xquery draft http://www.w3.org/TR/xquery-11/
> >
> > tracking http://www.w3.org/TR/xqueryx/
>I'm not sure what the verb "to track" means. I thought it meant something
>like "to follow". The answer to that is that the XQueryX syntax follows the
>XQuery syntax, not the other way around. In terms of moving it forwards to
>1.1, we do occasionally have problems that the evolution of syntax in XQuery
>leads to XQueryX changes that are not backwards compatible with XQueryX 1.0
>- I think we've managed around that problem, but I don't follow XQueryX that
> >
> > Were there arguments ever to model the grammer with xml then
> > derive a shorthand version of XQuery e.g. you have mentioned
> > the benefits but what are the limitations ?
>The problems with evolution of the XQuery grammar relate largely to the
>problem that arbitrary "bare names" can be used as expressions, but they can
>also be used as keywords, and the two uses of a name (or other symbol such
>as *, /, or .) are distinguished by context. XSLT avoids that problem
>because there are clearly different syntactic contexts - element names,
>attribute names, attribute values - distinguished by the XML parser before
>XSLT or XPath processing even starts.
> >
> > Also we saw some extensions at XML Prague of xquery
> > (presented by Matthias Brantner)
> >
> >
> > I found this to be rare demonstration of how XQuery can be
> > extended with a minimum of fuss and wondered if you had any
> > opinions on this as well.
>They've done two kinds of extension, as far as I can see:
>(a) new functions, which is unproblematic
>(b) new declarations in the prolog. The rule for a new prolog declaration to
>be unambiguous is that it must start with two keywords (for example "declare
>integrity") where the second keyword does not clash with a word that can
>appear in an operator context (such as "and", "then", "as", "with" - the
>list is quite long and growing because of Update and Free Text). They have
>taken a gamble that the words "collection", "integrity", "value", "ordered"
>will never be used in an operator context in a future version of the
>In XSLT, the second kind of extension can be done without breaking
>conformance and interoperability by using a top-level element (such as
><m28:declare-collection>) in a vendor namespace. Your stylesheet will then
>continue to run with products that don't recognize this extension. With
>XQuery extensions like these, your query becomes completely
>non-interoperable if you use the vendor extension.
>(Generally, the XQuery user community, perhaps because it grew out of the
>SQL user community, is far more tolerant of non-interoperability than the
>XSLT user community, whose expectations are set more by HTML: if you conform
>to the spec, you should get identical results in every browser, and if you
>don't, you still get a reasonable approximation in every browser.)
>Michael Kay
>XML-DEV is a publicly archived, unmoderated list hosted by OASIS
>to support XML implementation and development. To minimize
>spam in the archives, you must subscribe before posting.
>[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
>subscribe: xml-dev-subscribe@lists.xml.org
>List archive: http://lists.xml.org/archives/xml-dev/
>List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

Jim Melton --- Editor of ISO/IEC 9075-* (SQL)     Phone: +1.801.942.0144
   Chair, W3C XML Query WG; XQX (etc.) editor       Fax : +1.801.942.3345
Oracle Corporation        Oracle Email: jim dot melton at oracle dot com
1930 Viscounti Drive      Standards email: jim dot melton at acm dot org
Sandy, UT 84093-1063 USA          Personal email: jim at melton dot name
=  Facts are facts.   But any opinions expressed are the opinions      =
=  only of myself and may or may not reflect the opinions of anybody   =
=  else with whom I may or may not have discussed the issues at hand.  =

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

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

Copyright 1993-2007 XML.org. This site is hosted by OASIS