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

[Bug 29445] [XT30] select-2305, concatenation of sequences of strings

From: <bugzilla@jessica.w3.org>
Date: Wed, 10 Feb 2016 20:32:24 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29445-523-XDkcJavZ6t@http.www.w3.org/Bugs/Public/>

--- Comment #1 from Michael Kay <mike@saxonica.com> ---
I think the test is correct. It's written to test this rule in 11.4.3:

If the separator attribute is present, then the effective value of this
attribute is used to separate adjacent items in the result sequence, as
described in 5.7.2 Constructing Simple Content. In the absence of this
attribute, the default separator is a single space (#x20) when the content is
specified using the select attribute, or a zero-length string when the content
is specified using a sequence constructor.

I'm afraid I don't recall the full history of this rule (which was there in
2.0). xsl:attribute has the same rule, and it's possible that the rule was
added to xsl:attribute to achieve 1.0 compatibility, and was then applied to
xsl:value-of so that both would work the same way. Recall that in 1.0, the
content of attributes was always constructed using a contained sequence
constructor (no select attribute available), and the content of a text node was
always constructed using a select attribute (xsl:value-of had to be empty).
However I don't think that can be the full explanation because separators were
only introduced in 2.0 - in 1.0 all items after the first were discarded.

In 1.0 you could write

<xsl:attribute name="x">
  <xsl:copy-of select="keywords/keyword"/>

and you got all the keywords with no space-separation. I suspect we felt
obliged to retain that behaviour in 2.0, and then to make xsl:value-of do the
same thing.

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Wednesday, 10 February 2016 20:32:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:59 UTC