[xquery-talk] Reserved namespaces, and QNames as extension keywords

[Michael Kay]

> 
> I wonder if it makes at least some implementations not 
> compliant in that respect, then - e.g. Saxon seems to reserve 
> certain namespaces to map to Java/.NET types.

I've tried very hard in Saxon to do extensions in a way that preserves the
maximum level of interoperability. The specification allows functions,
types, etc to be added by the implementation to the static context, and
Saxon uses this mechanism. In most cases Saxon uses namespaces based on its
own registered domain name. An exception is made for URIs of the form
java:com.acme.package.Class which represent Java classes; this form of URI
evolved as a convention to allow interoperability between different
Java-based XSLT processors. And it's not in fact reserved; you can define
your own user-written functions in such a namespace and they will take
precedence.

> 
> >> 2) Assuming the answer to #1 is true, is it legal for a conforming 
> >> XQuery implementation to use QNames from such a reserved 
> namespace as 
> >> "keywords" (i.e. syntax elements for extension language 
> constructs),
> >
> > The only expression extension allowed is the pragma and the pragma 
> > only has influence over its associated expression:
> >
> >  (# pragma here #) { (:associated expression here:) }
> 
> ...
> The problem (well, one of the problems) I'm trying to solve 
> is demonstrated in my example - first-class function 
> literals. Defining values of that type is possible using 
> eval-like functions which take a string, e.s.:
> 
>   ext:lambda("($x as xs:integer, $y as xs:integer) as 
> xs:integer { $x + $y }")
> 

Many vendors are in fact adding syntactic extensions to XQuery. The
specification itself is unclear on what the rules for this are; I asked for
clarification in a bug report recently:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6027

What emerged in discussion is that most XQuery vendors want the freedom to
extend the language in arbitrary ways. Users appear to be tolerant of this,
probably because expectations of interoperability in the database world are
historically rather low. It's also true that in comparison with XSLT, the
extension points for the language are not particularly good (this is an area
where the use of an XML-based syntax gives XSLT a real advantage). My own
advice would be to implement your extensions in whatever way you want,
thinking about how to reduce the risk of conflict with future XQuery
versions, but require users to take explicit action to activate these
extensions so they know when they are departing from interoperable syntax.

On the specific area of first-class function literals, I would suggest
waiting until you see the next working draft of XQuery 1.1.

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