Re: comments on XSLT draft 13 August 1999

Thanks for your comments.

Paul Rabin wrote:

>         In order to handle the case where the desired result does not have a
> single root element, or alternatively, to permit inclusion of stylesheet
> content that does not have a single root element, it would be useful to
> define an XSLT instruction that can be used as a parent element, but has no
> other effect.  That is, the effect of instantiating this element would be
> simply to instantiate its children.

You can always do

<xsl:if test="true()">
...
</xsl:if>

I don't think this is common enough to be worth a separate instruction,
at least not in v1.

> 2) 2.6.1 Stylesheet Inclusion
>         It would be useful, and not difficult to implement, to be able to support
> xsl:include within a template, when the included stylesheet has the
> simplified (template body) format.

Maybe in v2.
 
> 5) 5.7 Modes
>         It would be useful to interpret mode attributes on xsl:template and
> xsl:apply-templates as attribute value templates, as for other QName-valued
> attributes.

We decided not to that.  It would violate the general principles about
when to allow attribute value templates and would inhibit highly
optimizing XSLT implementations.

>         It would also be useful to allow "*" as a wild-card mode.  On
> xsl:template, it would mean "match any mode"; on xsl:apply-templates, it
> would mean "continue the current mode".  Some such mechanism might be used
> in implementing the build-in templates, and could be made generally available.

An interesting idea but not for v1.

> 6) 7.1.3 Creating Attributes with xsl:attribute
>         It is reasonable that XSLT processors not be required to support
> stylesheets that try to add an attribute after adding child elements, but
> why should XSLT processors be prohibited from doing so?

Interoperability.

> 7) 7.1.4 Named Attribute Sets
>         This feature seems to add complexity without any functional benefit.  Why
> not just use named templates to do the same thing?  The convenience of
> being able to override attributes in attribute sets with attributes in
> literal result elements is not sufficient to justify this feature

That was the main reason for adding it.  This is a very common case when
XSLT is being used as part of XSL.

> 9) 11.2 Values of Variables and Parameters
>         The explanation of the first example in the NOTE appears to contradict
> 11.1 ("An operation is permitted on a result tree fragment only if that
> operation would be permitted on a string (the operation on the string may
> involve first converting the string to a number or boolean).").  And,
> assuming that using a value within [] is not the same as applying the []
> operator to it, the restrictions on use of a result tree fragment are not
> violated.

I don't follow you.

<xsl:value-of select="item['2']"/>

is legal and is the same as 

<xsl:value-of select="item[true()]"/>

and so will output the value of the first item.

> 10) 11.4 Top-level Variables and Parameters
>         Why not use the same visibility rules for top-level variables and
> parameters as for template variables and parameters: they are visible in
> following siblings and their descendents?  Forcing XSLT processors to
> handle forward references to other top-level variables and parameters adds
> complexity without any functional benefit.  Since circular references are
> prohibited anyway, there must be some ordering that eliminates forward
> references, so why not just prohibit forward references?

Avoiding any ordering constraints on top-level elements has been an
important design principle in XSLT.  They make life harder for
stylesheet authors especially with large stylesheets and they don't work
well with importing.  In particular, it's crucial that an importing
stylesheet can override a variable declaration in an imported stylesheet
and that the overriding declaration applies in the imported stylesheet.

James

Received on Wednesday, 1 September 1999 00:18:26 UTC