This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 29933 - [XSLT30] Discrepancy between serialization spec and XSLT spec on undeclare-prefixes
Summary: [XSLT30] Discrepancy between serialization spec and XSLT spec on undeclare-pr...
Status: RESOLVED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Candidate Recommendation
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-10-11 19:17 UTC by Abel Braaksma
Modified: 2016-10-13 19:28 UTC (History)
0 users

See Also:


Attachments

Description Abel Braaksma 2016-10-11 19:17:41 UTC
(probably only editorial, not sure)

About undeclare-prefixes we say:

<quote>
The undeclare-prefixes attribute is relevant only when producing output with method="xml" and version="1.1" (or later). It defines whether namespace undeclarations (of the form xmlns:foo="") SHOULD be output when a child element has no namespace node with the same name (that is, namespace prefix) as a namespace node of its parent element. The default value is no: this means that namespace undeclarations are not output, which has the effect that when the resulting XML is reparsed, the new tree may contain namespace nodes on the child element that were not there in the original tree before serialization.
</quote>

In Serialization 3.1 we say:

<quote>
...if the undeclare-prefixes parameter has the value yes, the output method is XML or XHTML, and the version parameter value is greater than 1.0, the serializer MUST undeclare its namespace. If the undeclare-prefixes parameter has the value no and the output method is XML or XHTML, then the undeclaration of prefixes MUST NOT occur.
</quote>

In other words, we write SHOULD were Ser 3.1 writes MUST and MUST NOT.

Also, we say "is relevant only", where the Ser 3.1 writes that it MUST signal an error SEPM0010 if this attribute is used with version="1.0" (and *if* method is XML or XHTML).

And we say it applies to "XML", where it also applies to "XHTML".

I propose therefore a slightly different wording, something along those lines:

<proposal>
The undeclare-prefixes attribute is relevant only when producing output with method="xml" or method="xhtml" and version="1.1" (or later), it raises an error (err:SEPM0010) when used with the value "yes" with these methods and version="1.0". It defines whether namespace undeclarations (of the form xmlns:foo="") MUST or MUST NOT be output when a child element has no namespace node with the same name (that is, namespace prefix) as a namespace node of its parent element. The default value is no: this means that namespace undeclarations are not output, which has the effect that when the resulting XML is reparsed, the new tree may contain namespace nodes on the child element that were not there in the original tree before serialization.
</proposal>
Comment 1 Michael Kay 2016-10-13 14:22:18 UTC
There is one difference between the specs which is, I think, deliberate: XSLT 3.0 says

<quote>
There are some serialization parameters that apply to some output methods but not to others. For example, the indent attribute has no effect on the text output method. If a value is supplied for an attribute that is inapplicable to the output method, its value is not passed to the serializer. The processor may validate the value of such an attribute, but is not required to do so.
</quote>

which means in effect that you have the option of ignoring "inapplicable" parameters even though the serialization spec says you can't.

In general though the mistake for undeclare-prefixes is that we say anything at all. Most of the descriptions of serialization parameters under xsl:output simply say something like

<quote>
The value of the omit-xml-declaration attribute provides the value of the omit-xml-declaration parameter to the serialization method. The default value is no.
</quote>

and we should do the same here.
Comment 2 Michael Kay 2016-10-13 19:28:06 UTC
Agreed by the WG: The detail of what this parameter does is now (like others) delegated to the serialization spec.