28486 2015-04-14 08:47:10 +0000 [XQ 3.1] Lexical form of serialization parameters 2015-07-09 22:12:33 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 3.1 Last Call drafts PC All RESOLVED FIXED P2 normal --- 1 mike jonathan.robie josh.spiegel tim public-qt-comments oldest_to_newest 119486 0 mike 2015-04-14 08:47:10 +0000 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. 119487 1 mike 2015-04-14 09:05:19 +0000 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. 119496 2 josh.spiegel 2015-04-14 14:39:13 +0000 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. 119497 3 mike 2015-04-14 14:55:52 +0000 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. 119498 4 josh.spiegel 2015-04-14 15:10:55 +0000 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. 119532 5 tim 2015-04-15 13:31:39 +0000 > 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. 119533 6 josh.spiegel 2015-04-15 13:54:50 +0000 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> 119536 7 mike 2015-04-15 14:59:12 +0000 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). 120268 8 jonathan.robie 2015-05-12 16:13:58 +0000 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. 120269 9 jonathan.robie 2015-05-12 16:14:55 +0000 The Working Group decided to accept comment #8 as the resolution of this issue. 121794 10 mike 2015-07-06 09:24:31 +0000 This change has not been applied in the current draft. 121919 11 josh.spiegel 2015-07-09 16:49:20 +0000 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" 121928 12 jonathan.robie 2015-07-09 22:12:33 +0000 Fixed using Josh's proposed wording.