Hi Jeni, and by the way thanks for your response to ch. 8.

> The sorting in document order of those elements that have the same
> sort key is guaranteed.

OK.  Good to know.

> > 6. What two ways can you use to generate a number giving the position
> >    of a node within the source tree?
> >
> > Answer:
> > position() and <xsl:number>.
> 
> position() will only work if you're processing the nodes in document
> order. Can you think of another way that will work even if you're
> processing the nodes in a different order?

Hmmm...
How about <xsl:value-of select="count(preceding-sibling::Myname) + 1" />
where Myname is the name of this element.  And if you wanted position
regardless of level, change the axis to preceding::.

> > (Side note: out of curiosity,
> > I tried adding in a fourth format using Unicode Khmer digit one,
> > &#x17E1;. XSLT Programmer's Reference says any Unicode digit one
> > should work. Saxon processed it properly, generating &#6115; (Khmer
> > digit three) for the third item; but IE/MSXML didn't seem to
> > recognize &#x17E1 as a digit.)
> 
> Hmm... I think that MSXML is non-conformant in that case. The XSLT
> spec says:
> 
>  "Any token where the last character has a decimal digit value of 1
>   (as specified in the Unicode character property database)...
>   generates a decimal representation of the number..."
> 
> KHMER DIGIT ONE (#x17E1) has a decimal digit value of 1 in the Unicode
> character property database, so it should be recognised.

For the format "&lt;&#x17E1;&gt;", MSXML generated
"&lt;&#x17E1;&gt;3&lt;&#x17E1;&gt;", i.e. apparently treating the
&#x17E1; as part of a punctuation token, and putting the whole
formatting string before and after the number 3.

I tried this with MSXSL on the command-line as well as in IE,
with the same result.

It would be nice if IE would let you specify whatever
external XSL processor you wanted to run... I would like to run
Saxon by default.

Lars


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