W3C home > Mailing lists > Public > xsl-editors@w3.org > April to June 1999

comments on the XSLT specification

From: <GignacDA@nswccd.navy.mil>
Date: Thu, 20 May 1999 14:29:13 -0400
Message-ID: <CF4572E241B4D11197F700A0C9890F78017261C9@crbenswcex02.dt.navy.mil>
To: xsl-editors@w3.org, WestbrookEL@nswccd.navy.mil, JunodLJ@nswccd.navy.mil
Cc: GarnerFJ@nswccd.navy.mil, LeBeauRP@nswccd.navy.mil

The following comments pertain to the April 21, 199 W3C working draft of
"XSL Transformations (XSLT) Specification Version 1.0" provided at
http://www.w3.org/TR/WD-xslt.

1. Section 2 "Stylesheet Structure" states:

The order in which the children of the xsl:stylesheet element occur is not
significant except for xsl:import elements and for error recovery. Users are
free to order the elements as they prefer, and stylesheet creation tools
need not provide control over the order in which the elements occur.

Since the content model of the "xsl:stylesheet"element type in the DTD
fragment in appendix A "DTD Fragment for XSL Stylesheets" is 

(xsl:import*, (xsl:include | xsl:strip-space | xsl:preserve-space | xsl:key
| xsl:functions | xsl:locale | xsl:attribute-set | xsl:variable |
xsl:param-variable | xsl:template)*) 

I recommend that that the above paragraph be rewritten along the lines of:

The first children of the xsl:stylesheet element must be the xsl:import
elements (if any). Subject to error recovery considerations,  users are free
to order the other elements following the xsl:import elements as they
prefer, and stylesheet creation tools need not provide control over the
order in which the elements occur.

for greater clarity.

2. Section 3 "Forwards-compatible Processing"states:

Thus any XSLT 1.0 processor must be able to process the following stylesheet
without error:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/XSL/Transform/1.1">
  <xsl:template name="/">
    <xsl:choose>
      <xsl:when test="system-property('xsl:version') >= 1.1">
        <xsl:exciting-new-1.1-feature/>
      </xsl:when>
      <xsl:otherwise>
        <p>Sorry this stylesheet requires XSLT 1.1.</p>
      </xsl:otherwise>
    </xsl:choose>
  </xsl:template>
</xsl:stylesheet>

The attributes of the "xsl:stylesheet" element type in the DTD fragment in
appendix A "DTD Fragment for XSL Stylesheets" are defined as:

<!ATTLIST xsl:stylesheet 	
result-ns 	NMTOKEN 	#IMPLIED 
default-space 	(preserve|strip) 	"preserve" 
indent-result	 (yes|no) 	"no" 
id 		ID 		#IMPLIED 
xmlns:xsl 	CDATA  	#FIXED "http://www.w3.org/XSL/Transform/1.0" 
%space-att; > 

2.1 The "1.1" in the "xmlns:xsl" attribute value on the tag 

<xsl:stylesheet xmlns:xsl="http://www.w3.org/XSL/Transform/1.1">

must be changed to "1.0" since "http://www.w3.org/XSL/Transform/1.0" is the
only value that the "xmlns:xsl" attribute can assume. XML "#FIXED"
attributes can only take the value following "#FIXED". Specifying any other
attribute value is an XML syntax error.

2.2 The two other "1.1" in the data of the above example: 

<xsl:when test="system-property('xsl:version') >= 1.1">

<p>Sorry this stylesheet requires XSLT 1.1.</p>

should be changed to "1.0" since the example is supposed to be for XLST
version 1.0.

2.3 The value of the "name" attribute on the "xsl:template" tag 

<xsl:template name="/">

is unacceptable. The attributes of the "xsl:template" element type are
defined as

<!ATTLIST xsl:template 
match 		%pattern; 	#IMPLIED 
name 		NMTOKEN 	#IMPLIED 
priority 		%priority; 	#IMPLIED 
mode 		NMTOKEN 	#IMPLIED 
%space-att; > 
  
in the DTD fragment in appendix A "DTD Fragment for XSL Stylesheets".
According to [7] "Nmtoken" and [4] "NameChar" in the current XML 1.0
specification (http://www.w3.org/TR/REC-xml), the "/"character is not
allowed in an NMTOKEN (name token) attribute value for the following reason.


An NMTOKEN attribute value consists of a delimited string of one or more of
following characters: the digits "0" through "9", the upper- and lower case
letters of the alphabet, the period ".", the dash "-", the underscore "_",
and the colon ":". The presence of any other character is an XML syntax
error. However, if the "name" attribute must take the "/" value, then the
"name" attribute in the DTD fragment must be redefined with CDATA declared
value.

2.5 The DTD fragment in appendix A "DTD Fragment for XSL Stylesheets" does
not define a "p" element type corresponding to the "p" element in the
"xls:content" in the above sample stylesheet. Presumably, the "p" element
type is provided in some way through the replacement text of the
"result-elements" parameter entity that must be defined for the DTD
fragment. In any event, such an element type is not required since there is
a "#PCDATA" option in the "xsl:otherwise" content model as be seen by
resolving "%template;" whose replacement text is defined as 

<!ENTITY % template " (#PCDATA %instructions; %result-elements;)* "> 

in the definition of the "xsl:otherwise" element type

<!ELEMENT xsl:otherwise %template;> 

In other words, 

<xsl:otherwise>
        <p>Sorry this stylesheet requires XSLT 1.1.</p>
      </xsl:otherwise>

could be rewritten as

<xsl:otherwise> Sorry this stylesheet requires XSLT 1.0.</xsl:otherwise>

See comment 2.2.

3. Section 5 "Using the Result Tree" contains the tag

<xsl:stylesheet
  xmlns:xsl="http://www.w3.org/XSL/Transform/1.0"
  xmlns="http://www.w3.org/TR/REC-html40"
  result-ns="">

in its example. The ATTLIST declaration for the "xsl:stylesheet" element
type in the DTD fragment in appendix A "DTD Fragment for XSL Stylesheets"is
provided in comment 2.3.

The null string ""  is not an acceptable value for the NMTOKEN (name token)
attribute "result-ns". A NMTOKEN attribute value must consist of a delimited
string of one or more characters. See comment 2.3. However, if the
"result-ns" attribute must take the "" value, then the "result-ns" attribute
in the DTD fragment must be redefined with CDATA declared value.
 
Received on Thursday, 20 May 1999 14:29:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:49 GMT