This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The XSLT 2.0 specification makes provision for implementations to define additional serialization parameters whose effect is implementation-defined. There seems to be no similar provision in the serialization specification itself. Implementation-defined serialization parameters should be allowed to override the standard serialization even where this is specified with MUST. For example, it would be acceptable for an implementation-defined serialization parameter to cause all whitespace text nodes in the output to be dropped.
I have an action A-251-02 to propose specific text to implement this suggestion. Here is proposed wording: take the following sentences at the start of section 3: <old> Host languages MAY allow users to specify any or all of these parameters, but they are not REQUIRED to be able to do so. However, the host language specification MUST specify how the value of all applicable parameters is to be determined. </old> and expand them as follows, moving the text to appear after the table of parameters: <new> Host languages MAY allow users to specify any or all of these parameters, but they are not REQUIRED to be able to do so. However, the host language specification MUST specify how the value of all applicable parameters is to be determined. Furthermore, host languages MAY define additional serialization parameters, and MAY permit implementations or users to define additional serialization parameters; the presence of such additional parameters MAY modify the result of serialization in arbitrary ways, including ways that override the provisions of this specification. For example, section 7.4.12 states that when using the HTML output method, relative URIs MUST NOT be absolutized. Despite this provision, it would be acceptable for a host language or an implementation (if permitted by the host language) to define an additional serialization parameter that causes relative URIs to be absolutized. </new>
The proposed text was rejected by the XSL and XQuery working groups in the F2F meeting held in July.
This proposal was rejected because the working group felt that the effect of those parameters is too open ended. If such effect is required by an implementation, it can be accomplished by defining a new output method.
The following text will be added to the end of section 3 to clarify support of extension attributes in serialization. Implementations may define additional serialization parameters, and may allow users to do so. For this purpose, the name of a serialization parameter is considered to be a QName; the parameters listed above are QNames in no namespace, while any additional serialization parameters must have names that are namespace-qualified. If the serialization method is one of the four methods xml, xhtml, html, or text, then such parameters may affect the output of the serializer to the extent (but only to the extent) that this specification leaves the output implementation-defined or implementation-dependent. For example, such parameters might control whether namespace declarations on an element are written before or after the attributes of the element, or they might define the number of space or tab characters to be inserted when the indent parameter is set to yes; but they could not instruct the serializer to suppress the error that occurs when the html output method encounters illegal characters (see error SERE014).