- From: Joanne Tong <joannet@ca.ibm.com>
- Date: Tue, 8 Mar 2005 15:03:12 -0500
- To: David Carlisle <davidc@nag.co.uk>
- Cc: public-qt-comments@w3.org
- Message-ID: <OFAA49B56A.DA5BB3FC-ON85256FBE.005C0A32-85256FBE.006E2934@ca.ibm.com>
Hi David You submitted a comment [1] on the October 29 Working Draft of XSLT 2.0 and XQuery 1.0 Serialization. Thank you for submitting this comment. The XSL and XML Query Working Groups discussed the comment and have agreed that a new step is needed to merge text nodes and remove any text nodes with values of zero length. The new step 6 is: [...] For each subsequence of adjacent text nodes in S5, copy a single text node to the new sequence equal to the values of the text nodes in the subsequence concatenated in order. Any text nodes with values of zero length are dropped. Copy all other items to the new sequence. The new sequence is S6. [...] May I ask you to confirm that this response is acceptable to you? Thanks, Joanne [On behalf of the XSL and XML Query Working Groups] [1] http://lists.w3.org/Archives/Public/public-qt-comments/2004Nov/0075.html >From: David Carlisle <davidc@nag.co.uk> >To: public-qt-comments@w3.org >Date: Mon, 22 Nov 2004 16:24:56 GMT > >Section 2 defines the normalisation step three ways (in English, in >XSLT and in XQuery) unfortunately I don't think they are equivalent. >I think the intention is to get the effect of the xslt/xquery code >but I don't think the prose does this. The prose could be corrected >but >defining things in "equivalent" ways, even if two of them are in a >non-normative note is dangerous, and it might be better _just_ to >give >an unambiguous definition (in XSLT and/or Xquery) and drop the prose >description. > > >The problem with the existing text definition is I believe with >concatenation of text nodes. > ><xsl:result-document> > <xsl:copy-of select="$seq"/> ></xsl:result-document> > > >would merge any adjacent text nodes into a single text node with the >concatenated string and drop any empty text nodes (as they would >acquire >a parent after copying. adjacent text nodes may arise either because >they were in adjacent positions in the original sequence, or may >"become >adjacent" as a result of taking the children of document nodes, or >converting atomic strings to text nodes (steps 4 and 5). > >So if you want to keep the existing text I think you need to make S6 >into S7 and add a new S6 that merges adjacent text nodes and removes >text nodes with value the empty string. > >David >
Received on Tuesday, 8 March 2005 20:08:27 UTC