Re: Future XSLT expansion.

Subject: Re: Future XSLT expansion.
From: David Carlisle <davidc@xxxxxxxxx>
Date: Mon, 20 Mar 2000 10:04:28 GMT
Didier writes

> Thus, it is also my understanding that applying templates to the result tree
> is valid and conformant to the specs. But, as I said, I may be wrong.

You can not apply templates to result tree fragments.

Actually I agree with the MS implementors that the distinction between
result tree fragments and node sets is largely bogus (I just don't agree
that an implementation should follow logic rather than the spec).

> Conclusion: Now the question is: Can an implementer implement the result
> tree simply as a single member node set and thus have result trees processed
> as node sets. If this is so, is it compliant to the recommendation.

Yes. No.

xt:node-set() and the equivalents in saxon etc are essentially no ops
that just view the result tree as a node-set for the purposes of staying

If XSLT 1.0 had wanted to allow this usage (and I am not sure why it
didn't) then it is fairly clear that it would not have been done by
putting node-set()function into the core, but rather just by not having
the concept of result tree fragment at all, (as in the current microsoft

I am not at all sure which would be the best route for xslt 2.0
(assuming there will be such a thing). Having node-set() in the core or
dropping the result tree fragment type and having xsl:variable body
construct a node set (with a single root node). The latter option looks
cleaner but is more incompatible with existing systems.


 XSL-List info and archive:

Current Thread