W3C home > Mailing lists > Public > xsl-editors@w3.org > July to September 1999

Re: Operations on result tree fragments

From: James Clark <jjc@jclark.com>
Date: Tue, 27 Jul 1999 18:50:47 +0700
Message-ID: <379D9D17.CCE28690@jclark.com>
To: Kay Michael <Michael.Kay@icl.com>
CC: "'xsl-editors@w3.org'" <xsl-editors@w3.org>
12.1 goes on to say that

> The only
> operations that can be performed on a result tree fragment are to
> convert it to a string, a number or a boolean. These conversions are
> performed exactly as if the result tree fragment were the equivalent
> node-set.

The idea is that

- the operations that are allowed on result tree fragments behave the
same as if the result tree fragment were the equivalent node-set (so
that this restriction can be lifted in a future version if experience
shows it to be desirable to do so)

- the only operations that are allowed are those whose first step is to
convert the node-set to a string, a number or boolean

If you can suggest wording that would make this clearer, I would be
happy to include it. Perhaps change "are to convert it to" to "are those
that start by converting it to"?

Kay Michael wrote:
> 
> 12.1 says that the operations permitted on a result tree fragment are a
> subset of those permitted for a node set, but it does not say precisely what
> set of operations is permitted, or give the rules for them.
> 
> For example, where $val is a result tree fragment, it does not explicitly
> say that @name=$val is a permitted operation; and if this operation is used,
> it does not say how it proceeds. The "natural" approach is to convert $val
> to a string and compare it as such, but I can't see anything in the spec
> that justifies this.
> 
> (Unfortunately the fact that fragments aren't recognised by XPath means that
> many of these rules are not in their natural place).
> 
> Mike Kay
Received on Tuesday, 27 July 1999 07:51:25 GMT

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