Hi Joe,

> > More over, how do you explain the semantics of saxon:return
> > in terms of the current XSLT processing model?

> saxon:return is, I think, _fairly_ easy to explain in terms of the
> XSLT 1.0 processing model.  You just need to augment the the data
> model a bit.

Well, almost anything could have a simple and natural explanation
if you redefine your universe.

> 'saxon:assign' on the other hand would involve a much bigger change
> to the XSLT semantics, but I think it's doable as well.

Doable but not sensible. It would pretty effectively prevent
important optimizing methods like, for example, lazy evaluation.

> I *think* that Mike Kay's brief description on the Saxon home
> page is well-defined in the context of XSLT 1.0 (if you assume a certain
> "natural" processing order), but it's not clear (to me, anyway)
> how it should interact with first-class result trees,
> saxon:function, and various other proposed extensions.

It may be well-defined in the context of SAXON, no more, no less.

Cheers,

</David>

David Rosenborg
Pantor Engineering AB


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