RE: Inconsistency between XPath 1.0 and XSLT 1.0 treatment of processing instruction initial whitespace

 

> -----Original Message-----
> From: xsl-editors-request@w3.org 
> [mailto:xsl-editors-request@w3.org] On Behalf Of Elliotte Harold
> Sent: 20 July 2004 14:14
> To: xsl-editors@w3.org
> Cc: xsl-list@lists.mulberrytech.com
> Subject: Inconsistency between XPath 1.0 and XSLT 1.0 
> treatment of processing instruction initial whitespace
> 
> 
> I've encountered an apparent discrepancy between how the 
> xsl:processing-instruction element behaves and the XPath 1.0 
> data model.
> 
> The XPath 1.0 data model specifically excludes leading white 
> space from 
> the string-value of a processing instruction node:
> 
> The string-value <http://www.w3.org/TR/xpath#dt-string-value> of a 
> processing instruction node is the part of the processing instruction 
> following the target and any whitespace.

I don't read it that way. The XPath 1.0 data model generally describes how
nodes in the tree relate to the contents of source XML. This is saying that
when you create a processing instruction by parsing XML, there won't be any
whitespace in the value. It doesn't say that the string-value of a PI will
never contain leading whitespace. It does mean that the data model can't be
round-tripped through serialization and parsing, but I think people can live
with that.

> 
> In other words, the xsl:processing-instruction element 
> appears able to 
> create processing instructions that are not legal in the 
> XPath 1.0 data model.

No: only processing instructions that can't be generated by parsing lexical
XML.
> 
> Advice and comments would be appreciated. If I'm not missing 
> something 
> here, an erratum or clarification might be called for.

I think the world has lived quite happily with this problem for
four-and-a-half years and is unlikely to come to grievous harm if we let it
fester for a bit longer. There are bigger fish to fry.

It's probably something we should tighten up for 2.0.

Michael Kay

Received on Tuesday, 20 July 2004 10:38:57 UTC