This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
XQuery section 2.2.4 defines XQuery serialization parameters ("declare output") by reference to Serialization section 3. But serialization section 3 describes only the value space of these parameters, not their lexical form. It's up to the host language to specify the lexical form, but it fails to do so. For example, a number of serialization parameters are defined to contain (one or more) expanded QNames. (method, cdata-section-elements, suppress-indentation, json-node-output-method). The term "expanded QName" links (indirectly) to the definition in XPath 3.1. The definition of "expanded QName" describes the value space, not the lexical representation. So it's unclear how expanded QNames are actually written in the declare output declaration. There needs to be a statement that a QName can be written as an EQName; there should also be a statement about the default namespace that is used when a name is written as a simple NCName (it should be the default namespace for elements and types). The problem applies to all serialization parameters, but it is particularly acute for those containing QNames. Another aspect of the lexical representation that is left underspecified is boundary whitespace: it should say that for list-valued parameters such as suppress-indentation that the list is whitespace-separated, and for all parameters, it should say that leading and trailing whitespace is trimmed.
A particular issue with the parameters "method" and "json-node-output-method": there should be no default namespace for these. Method "xml" should mean "xml", not "xml" in the default namespace for elements and types.
As I recall, the WG previously decided that the lexical space is defined by the schema for serialization parameters. In 2.2.4: "Except for parameter-document, each option corresponds to a serialization parameter element defined in Section B Schema for Serialization Parameters SER31. The name of each option is the same as the name of the corresponding serialization parameter element, and the values permitted for each option are the same as the values allowed in the serialization parameter element." For example, I think the intent is that the lexical space for "method" is that of "method-type" in the schema for serialization parameters. See comments 10, 11, and 12 on bug 15390.
Thanks for the reference. Comments 12 on bug 15390 concerns the namespace context for resolving QNames, and appears to be unanswered. In my view using the default namespace for elements and types to resolve the method name "xml" would be horribly confusing.
If the value for "method" is "xml", it would be a string - not a QName (recall "method-type" is a union). The part in comment 12 about using the default element/type namespace relevant for parameters like cdata-section-element.
> So it's unclear how expanded QNames are actually written in the declare > output declaration. There needs to be a statement that a QName can be > written as an EQName; there should also be a statement about the default > namespace that is used when a name is written as a simple NCName (it should > be the default namespace for elements and types). Our implementation does NOT use the default element/type namespace for declare option output:method declare option output:cdata-section-elements declare option output:suppress-indentation and so we think that your assertion "it should be the default namespace for elements and types" is up for debate.
Consider this query: declare default element namespace "http://example.org"; declare option output:method "xml" declare option output:cdata-section-elements "foo"; <foo>bar</foo> I think the least surprising serialization is: <foo xmlns="http://example.org"><![CDATA[bar]]></foo>
Certainly XSLT has always had the rule that for <xsl:output cdata-section-elements="foo"/>, the default namespace applies. (XSLT of course distinguishes the default namespace for input elements and that for output elements).
The specification currently says this: <quote> Except for parameter-document, each option corresponds to a serialization parameter element defined in Section B Schema for Serialization Parameters SER31. The name of each option is the same as the name of the corresponding serialization parameter element, and the values permitted for each option are the same as the values allowed in the serialization parameter element. </quote> This needs to be extended to say that the namespace context is the set of statically known namespaces and to allow EQNames.
The Working Group decided to accept comment #8 as the resolution of this issue.
This change has not been applied in the current draft.
I think the decision needs to be extended such that the default element/type namespace is used in cases where the QName has no prefix. e.g. "For QName values, the EQName syntax is allowed and prefixes are expanded to namespace URIs by means of the statically known namespaces, or if unprefixed, the default element/type namespace"
Fixed using Josh's proposed wording.