W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2005

[Bug 1319] definition of a XSLT processor

From: <bugzilla@wiggum.w3.org>
Date: Fri, 20 May 2005 21:37:22 +0000
To: public-qt-comments@w3.org
Cc:
Message-Id: <E1DZFBK-0000xO-3R@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1319





------- Additional Comments From mike@saxonica.com  2005-05-20 21:37 -------
A further progress report following XSL WG meetings this week:

(a) we decided that a transformation always produces at least one result tree.
Contrary to what's stated in a couple of places at the moment, if the initial
template returns an empty sequence and if xsl:result-document has not been
called, then an empty result tree should be produced (in practice, if you are
serializing, the output destination should be overwritten with an empty file).

(b) we realized that there's a problem with the current text if the initial
template has an "as" attribute, for example if it is:

<xsl:template match="xs:integer+">
  <xsl:sequence select="1 to 5"/>
</xsl:template>

The current rules say this is equivalent to

<xsl:template match="xs:integer+">
 <xsl:result-document>
  <xsl:sequence select="1 to 5"/>
 </xsl:result-document>
</xsl:template>

which would give a type error; but that's problematic since we don't know in
advance which template will be the initial entry template.

(c) we also realized that there's nothing in the spec currently which says
whether or not an implementation is allowed to provide alternative processing
models for running the code in a stylesheet, for example by calling an
xsl:function directly from the API.

So we're leaving the bug open for the moment as our placeholder for sorting out
these issues with the processing model.

Michael Kay
Received on Friday, 20 May 2005 21:37:25 UTC

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