[XQuery] SAG-XQ-003 Run-time access to static namespace context

SAG-XQ-003 Run-time access to static namespace context

There are a very small number of constructs in the XQuery draft that require
run-time knowledge of the static namespace context. We feel that these
constructs are undesirable.

(a) they create a dependency on the choice of prefixes that is not apparent
to the casual reader of a query, leading possibly to failures if the
prefixes are changed.

(b) they create complexities for implementors and run-time overheads,
especially for products that act as compilers rather than interpreters,
because the amount of information that needs to be retained in the compiled
code is greatly increased.

(c) they offer no functionality that cannot be achieved in some other way,
just as conveniently.

The constructs that require access to the static namespace context are:

- computed element and attribute constructors
- casting string to QName (and perhaps NOTATION)

(the latter also affects XPath)

In computed element and attribute constructors, we allow the name of the
element or attribute to be evaluated either as a value of type xs:QName, or
as a string in the lexical form of a QName. The second option is useful only
(a) where the desired name is in no namespace (and there is no default
namespace), and (b) where the desired namespace URI is known statically, but
the desired local name is computed. I think that we should retain the option
to supply the value as a string, but in this case it must be in the form of
an NCName, and the resulting node will be in no namespace. For the second
case, it is just as easy to construct an xs:QName dynamically by calling the
expanded-QName function.

For casting a string to a QName, the cast can only succeed if the prefix is
one that has been statically declared. In practice this means that the
namespace URI must either be known in advance, or must be one of a small set
of possible namespace URIs. This scenario is not especially plausible, and
when it does occur, it is just as easy to use the expanded-QName function to
construct the required QName.

In fact the main use case for casting string to QName is where the string is
supplied as a literal, for example in the constructor
xs:QName("xs:integer"). This is needed for example in an argument of a
function call where a value of type xs:QName is required. We could meet this
use case either (a) by treating the xs:QName() constructor as a special
case, and requiring the argument to be a string literal, or (b) by providing
custom syntax for QName-literals.

Michael Kay
for Software AG