Re: Functional programming in XSLT

Hi Alexey,

> Funny enough, these three SAXON functions *do not*, at my opinion, break
> the XSLT processing model in any substantial way. As the matter of fact,
> I had never seen any "official" manifest, which would state that XSLT
> belongs to the family of functional languages. It happened that few XSLT
> experts had discovered a way for (ab)using xsl:call-template in a
> functional style, and this appeared to be the only way to handle many
> practically important issues with the 100% pure XSLT. These three SAXON
> functions might be not conforming to the certain cultural tradition, but
> not to the XSLT processing model itself.

>From 5.1 in the XSLT spec:

"Implementations are free to process the source document in any way that produces the same result as if it were processed using this processing model"

This statement is pretty hard to maintain if you introduce mutating variables. For example, a particular implementation
may utilize lazy evaluation, execution reordering and multithreading. If you use mutating variables in that situation, things
can go very wrong. Yes, it can work perfectly well within another implementaion, say SAXON, but in the
general case, it breaks the processing model. More over, how do you explain the semantics of saxon:return
in terms of the current XSLT processing model?

Cheers,

</David>

David Rosenborg
Pantor Engineering AB




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