- From: David Carlisle <davidc@nag.co.uk>
- Date: Mon, 22 Nov 2004 16:24:56 GMT
- To: public-qt-comments@w3.org
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 ________________________________________________________________________ This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________
Received on Monday, 22 November 2004 16:25:18 UTC