[Bug 29831] [FO31] fn:transform and serialization to string

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29831

--- Comment #1 from Michael Kay <mike@saxonica.com> ---
Looking at the spec, I think it is as clear as it needs to be.

Firstly, it's clear how you request a serialized result, and it's clear that
serialization-params specified in the request take precedence over those
specified in xsl:output.

There is a slight mismatch because we require the serialized result as a
string. The serialization spec says:

Note:
Serialization is only defined in terms of encoding the result as a stream of
octets. However, a serializer MAY provide an option that allows the encoding
phase to be skipped, so that the result of serialization is a stream of Unicode
characters. The effect of any such option is implementation-defined, and a
serializer is not required to support such an option.


and we might perhaps refer to that note. If the serializer does not support
serialization to a string, then the stream of octets can always be decoded as a
string. It might be worth mentioning that there are two possible ways of doing
this: either skip the encoding phase (in which case escaping of non-encodable
characters probably doesn't happen), or decode the octet stream (in which case
you're probably left with character references for unencodable characters).

Support for disable-output-escaping in XSLT has always been optional, and
remains so for the fn:transform function. It's a deprecated feature and I don't
think we need to say anything about it: if you use it, you're not guaranteed
interoperable.

I don't see any reason to restrict the output methods available. HTML and JSON
make perfectly good sense, for example.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 20 September 2016 18:54:03 UTC