[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Future XSLT expansion.
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 conformant. 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 implementation). 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. David XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|