QName arguments: also allow strings

[ChristianGruen]

In #747, a syntax for QName literals was proposed (Q"prefix:local"). Concerns were raised that the new syntax could be mixed up with the existing Q{URI}local syntax, and that too many syntax variants are confusing.

In attribute and element constructors, it is already possible to supply prefix:local-name and Q{uri}local strings for names:

element { 'xml:name' } {},
element { 'Q{uri}name' } {}

With option declarations, it is possible to write:

declare option output:cdata-section-elements 'xml';
<xml>text</xml>

…and it is counterintuitive that serialize($xml, { 'cdata-section-elements': 'xml' }) is not legal.

I wonder whether we cannot simply allow both QNames and strings for arguments (and arguments in options) in the existing standard functions. There are fewer cases than I had suspected:

Function	Argument
fn:error	$code
fn:format-number	$options: format-name (can also be xs:NCName)
fn:deep-equal	$options: unordered-elements
fn:serialize	$options: cdata-section-elements, suppress-indentation
fn:function-lookup	$name
fn:load-xquery-module	$options: variables, vendor-options
fn:transform	$options: initial-function, initial-mode, initial-template, ...
fn:elements-to-maps	$options: layouts
fn:schema-type	$name

For some options, like the method option of fn:serialize, we already allow both strings and QNames.

[ChristianGruen]

We could additionally introduce mutual coercion of strings and QNames:

• xs:string → xs:QName: Accept "local"/"Q{uri}local", raise error for "prefix:local" (unless the prefix is statically known?)
• xs:QName → xs:string: Rewrite to "Q{uri}local"

[michaelhkay]

Note also in XSLT, fn:system-property, fn:element-available, fn:function-available, fn:key etc traditionally required a lexical QName (as a string) and more recently have allowed an xs:QName.

Despite this, I have some hesitation in increasing the number of places where the static namespace context has to be retained at execution time.

[michaelhkay]

I'm starting to come around to extending the coercion rules so that if the required type is xs:QName, a string that can be converted to a QName by calling fn:parse-QName should be accepted.

I have reservations about doing this in dynamic function calls, however, where it isn't statically known what the required type will be; we don't want to have to retain the static namespace for a dynamic function call just in case.

[ChristianGruen]

I have reservations about doing this in dynamic function calls, however, where it isn't statically known what the required type will be; we don't want to have to retain the static namespace for a dynamic function call just in case.

To understand this correctly:

• Would this mean that xs:QName('xml:a'), xs:QName#1('xml:a') and error('xml:a') could be evaluated, but error#1('xml:a') could not?
• Aren’t components of the static context already preserved in other existing dynamic function calls, such as resolve-uri#1('a')?

[michaelhkay]

Aren’t components of the static context already preserved in other existing dynamic function calls

I think that in general, we know statically which parts of the static context are needed by an expression, and we only need to retain those parts when compiling the expression. Retaining the static namespace context for every dynamic function call, just in case it turns out to have QNames in the function signature, would be very expensive. It's possible to make economies by noting that the static context of an expression is in many cases the same as its parent expression, but that kind of thing makes expression rewrites such as loop-lifting more complex.

[ChristianGruen]

Retaining the static namespace context for every dynamic function call, just in case it turns out to have QNames in the function signature, would be very expensive.

I could imagine that the incurred costs are implementation-specific, but maybe I should first implement it before judging it (if I remember correctly, we simply keep a reference to an existing static context in dynamic functions).

In any case, most function calls are certainly static, so it would already be a good improvement to support those.