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

[Bug 29431] New: [XSLT30] item-separator applicability

From: <bugzilla@jessica.w3.org>
Date: Sun, 07 Feb 2016 20:10:36 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29431-523@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29431

            Bug ID: 29431
           Summary: [XSLT30] item-separator applicability
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 3.0
          Assignee: mike@saxonica.com
          Reporter: abel.braaksma@xs4all.nl
        QA Contact: public-qt-comments@w3.org
  Target Milestone: ---

Not necessarily related to bug 29424.

I have trouble finding out the scope of the applicability of the item-separator
attribute. We say at several occasions that it only applies when build-tree is
false and item-separator is set to anything but "#absent".

# Pm @build-tree

Build-tree may be a bit of a misnomer, as I think it is not preventing to build
a (sequence of) tree(s), but it prevents wrapping the result in a document
node. Build-document, or build-document-node, or serialize-to-document-node
(ouch) seems to cover it better.

# On @item-separator

My gut tells me it is only applicable to method="text" or "json", but the text
indicates otherwise. Does this mean that if you create a sequence of two
elements, say "<a>1</a><b>2</b>" and item-separator="###", the (serialized!)
result becomes "<a>1</a>###<b>2</b>"?

I would assume it only applies to the "root sequence", though we don't say that
explicitly, I think.

We also say on several occasions that text nodes are merged together. I don't
see how that works here. Suppose you have:

<xsl:template match="/">
   <xsl:text>A</xsl:text>
   <xsl:text>B</xsl:text>
   <xsl:text>C</xsl:text>
</xsl:template>

When and how do we merge the text nodes? If we do it early, this is serialized
as "ABC", if we do it as late as possible, we get "A###B###C". But I am unsure
whether this may disrupt existing practices. My gut here says that
item-separator does not come into play and we should return "ABC" always, but I
don't know why exactly.

Then, compare that with:

<xsl:template match="/">
   <xsl:sequence select="'A', 'B', 'C'" />
</xsl:template>

which is supposed to return as "A B C" without the item-separator present and
*with* it as "A###B###C".

Note: we may be saying it clearly, I just can't find it and I don't know how it
relates to the different output methods.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Sunday, 7 February 2016 20:10:39 UTC

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