translation

Re:

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.

However, "The content of the |xsl:processing-instruction| element is a 
template for the string-value of the processing instruction node." It is 
an error if this template contains non-text nodes. However, it is not an 
error if this template contains leading white space. For example, this 
case from the OASIS Microsoft XSLT comformance test suite is legal:

<xsl:template match="/">
BEFORE
   <xsl:processing-instruction name="testcase">
This is the content of a PI
   </xsl:processing-instruction>
AFTER
</xsl:template>
</xsl:stylesheet>

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.

Advice and comments would be appreciated. If I'm not missing something 
here, an erratum or clarification might be called for.

--
Elliotte Rusty Harold

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

> -----Original Message-----
> From: xsl-editors-request <at> w3.org 
> [mailto:xsl-editors-request <at> w3.org] On Behalf Of Elliotte Harold
> Sent: 20 July 2004 14:14
> To: xsl-editors <at> w3.org
> Cc: xsl-list <at> 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

Re: Place fo:marker children into FO content models

Editors,

This is in reference to my previous email [1] recommending listing 
fo:markers directly within the content model.  It appears from another's 
comment on a related topic (which pointed to rule 51 of the XML 
recommendation [2]), that at least #2 and #8 of my suggestions were 
incorrect because evidently nothing may precede #PCDATA in a mixed 
content model. 

If so, it may be helpful for the SG to adopt another syntatical model 
that would allow a fuller specification of the precise ordering of child 
elements (i.e., without the DTD-mandated constraints), especially as the 
number of FO's defined within the recommendation increases.

[1] http://lists.w3.org/Archives/Public/xsl-editors/2004AprJun/0072.html
[2] http://www.w3.org/TR/2004/REC-xml-20040204/#sec-mixed-content

Thanks,
Glen Mazza
Apache FOP Team