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 29392 - [xslt 3.0] Serialization Feature and the fn:serialize() function
Summary: [xslt 3.0] Serialization Feature and the fn:serialize() function
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Candidate Recommendation
Hardware: PC All
: 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-01-25 22:32 UTC by Michael Kay
Modified: 2016-02-19 14:32 UTC (History)
0 users

See Also:


Attachments

Description Michael Kay 2016-01-25 22:32:31 UTC
XSLT 3.0 (like previous versions) defines Serialization as an optional feature. A processor that does not implement this feature should not be required to implement the fn:serialize function.
Comment 1 Michael Kay 2016-02-15 10:03:18 UTC
The minutes record: We accepted in principle that the function should be part of the serialization feature and MKay will come up with a proposal to make that happen.
Comment 2 Michael Kay 2016-02-15 11:23:06 UTC
Noted that F+O already states:

If the host language makes serialization an optional feature and the implementation does not support serialization, then a dynamic error [err:FODC0010] is raised.

There was discussion about "cherry-picking" - are implementations allowed to offer partial support for serialization, e.g. some methods but not others, some serialization params but not others, or fn:serialize() without external serialization. (MK's view - they will do so whether we allow it or not).

PROPOSAL (for XSLT - the section on Conformance / Serialization Feature):

If the Serialization Feature is not available and fn:serialize() is called with values for serialization parameters that are not supported, then a processor MUST raise error FODC0010 

(and add notes to say what this means - a processor might reject all calls on fn:serialize, or it might support only selected options.)

This proposal was accepted.
Comment 3 Michael Kay 2016-02-19 14:32:12 UTC
I interpreted our decisions as follows, by adding the text:

Note: A processor that does not claim conformance with the serialization feature
<rfc2119>may</rfc2119> offer alternative serialization capabilities, and these
<rfc2119>may</rfc2119> make use of the serialization parameters defined on
<elcode>xsl:output</elcode> and/or <elcode>xsl:result-document</elcode>.</p>

If the processor claims conformance with the serialization feature then it <rfc2119>must</rfc2119> fully implement the <xfunction>serialize</xfunction> function defined in <bibref ref="xpath-functions-30"/> or <bibref ref="xpath-functions-31"/> as appropriate, and <rfc2119>must not</rfc2119> raise error FODC0010 as the result of such a call.
            
If the processor does not claim conformance with the serialization feature, then it <rfc2119>may</rfc2119> raise error FODC0010 in respect of some or all calls on the <xfunction>serialize</xfunction> function; it <rfc2119>must not</rfc2119> return a result from a call on this function unless the result is conformant with the specification, given the parameters actually supplied.