Comments on XSL specification

The following comments on WD-xsl-19981216 arise from implementing the
specification. They all relate to the transformation language.

2.6.2 [23] Parents. The spec does not define whether an element is to be
treated as the parent of nodes that are not its children, e.g. attribute
nodes, comments, etc.

2.6.2 [32] EqualityExpr. I believe the implicit "there exists" in this
construct is potentially confusing: the problems show up when the syntax is
extended to include, for example, a not-equals operator. It would be better
to use explicit quantifiers:
  any s=value
  all s=value
  first s=value

2.7.6 and 2.7.7 I cannot find any rule that defines the order in which nodes
are
processed in the absence of xsl:sort. Presumably they are supposed to be
processed in document order, except for attribute nodes where the order is
undefined: but the spec doesn't seem to say this. 

2.7.9 Sorting: there is nothing that says what happens to nodes that have a
null value for the sort key.

2.7.10.1 Numbering: when numbering a node that does not match the supplied
"count" pattern, the current result is the number of the next node that
matches the pattern. It would be more intuitive to return the number of the
previous node that matches the pattern.

2.7.10.2 Counters. The use of a single command, counter-reset, to declare a
new counter and to reset the value of an existing counter is error-prone,
given that there can be several counters with the same name attached to
different elements of the result tree. It would be safer to have a separate
counter-create command.

My own inclination would be to extend the "counters" mechanism to allow full
integer arithmetic including the ability to test counter values, to set a
counter to an arbitrary value, to compute the dimensions of formatting
objects, to break a for-each loop when the counter exceeds a given value,
and so on.

2.7.11.1 conditional processing.

(a) I find it more natural for the condition to be a match pattern rather
than a select pattern. It is also more powerful, given that one can then
write test=".[select-pattern]".

(b) I have experimentally implemented the sequence
<xsl:if>
<xsl:then>...</xsl:then>
<xsl:else>...</xsl:else>
</xsl:if>
and find this usefully enhances the existing facilities. (It also coexists
with them).

2.7.13.1 String expressions

(a) I have implemented the experimental syntax:
  (select-pattern "/")? "^" attribute-name
to get the value of an inherited attribute

(b) I have found it useful to allow a literal (in quotes) as a string
expression 

2.7.13.2 xsl:value-of

I have found it useful to implement a "default" attribute that gives a value
to be used if the string expression is null.

General: grouping

There have been many queries on the xsl forums about how to do grouping. I
have experimentally implemented a construct that does this. Example:

<table>
<xsl:for-each select="child" group-by="@surname"/>
<tr><td><xsl:value-of select="@surname"/></td>
    <td><xsl:item>
		<xsl:value-of select="@givenname"/><br/>
	  </xsl:item></td>
</tr>
</xsl:for-each>
</table>

The formatting elements outside the <xsl:item> are executed once for each
group of nodes with the same value for the group-by expression; the elements
inside <xsl:item> are executed once for each selected node.

General: terminology

Stylesheet elements of the form <xsl:*> are sometimes called "elements" and
sometimes "instructions". It would be useful to use the term "instructions"
systematically, and define it up front.



Regards,
Michael Kay, ICL
Michael.Kay@icl.com