- From: <bugzilla@jessica.w3.org>
- Date: Wed, 10 Feb 2016 20:32:24 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29445 --- 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"/> </xsl:attribute> 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