XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
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: xquery v1.1 tracking xquery x was Re: [xml-dev] RE: Declarative programming requires a different mindset

> 
> 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
closely.
> 
> 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) 
>
http://www.xmlprague.cz/2010/sessions.html#Extending-XQuery-with-Collections
-Indexes-and-Integrity-Constraints
> 
> 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
standard.

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.) 

Regards,

Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay 



[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