comments on XSLT draft 13 August 1999

Subject: comments on XSLT draft 13 August 1999
From: Paul Rabin <prabin@xxxxxxx>
Date: Tue, 31 Aug 1999 14:32:59 -0400
Comments on the XSLT draft of 13 August 1999

0) General
	Overall, this specification is very clearly written.  An index or other
navigation aid keyed by feature name would increase its usefulness as a
reference.

1) 2.3 Literal Result Element as Stylesheet
	The requirement that the root element of a simplified stylesheet be a
literal result element seems overly restrictive.  Why not allow the root
element to be any element that could be a child of an xsl:template element?
	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.

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.

3) 3.1 Root Node Children (editorial)
	"may not" should be changed to "need not", to avoid ambiguity.

4) 5.5 Conflict Resolution for Template Rules (editorial)
	"-0.25" is in the wrong font

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.
	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.

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?

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, and the
precedence rule that enables that behavior is confusing.

8) 7.3 Creating Processing Instructions (editorial)
	The NOTE should also say that xsl:output can be used for the purpose of
outputting an XML declaration.

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.

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?

11) 16 Conformance
	It would be useful to define conformance for both stylesheets and XSLT
processors, since it makes sense to validate them independently.

-----------------------------------------------------------------------

Paul Rabin
Object Design, Inc. - eXcelon Division



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread