W3C home > Mailing lists > Public > public-qt-comments@w3.org > September 2016

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

From: <bugzilla@jessica.w3.org>
Date: Tue, 20 Sep 2016 18:53:55 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29831-523-KUFBRA77l5@http.www.w3.org/Bugs/Public/>

--- 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:

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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:58:02 UTC