Re: [xsl] Functional programming in XSLT

Subject: Re: [xsl] Functional programming in XSLT
From: Joe English <jenglish@xxxxxxxxxxxxx>
Date: Fri, 16 Mar 2001 18:31:55 -0800
David Rosenborg wrote:

> Hi Alexey,
> > Funny enough, these three SAXON functions *do not*, at my opinion, break
> > the XSLT processing model in any substantial way. [...]
>
>From 5.1 in the XSLT spec:
>
> "Implementations are free to process the source document in any way that prod
> uces the same result as if it were processed using this processing model"
> This statement is pretty hard to maintain if you introduce mutating variables
> [...]
> Yes, it can work perfectly well within another implementation,
> 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?

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.

An XSLT instruction is a function which takes a context as input
and returns a list of result nodes, where context = { context node,
context node list, variable bindings, function library, etc. },
and result node = { element node | attribute node | text node | etc.  }

To account for saxon:function and saxon:return, just define a new
type of result node (call it a "value" node) which holds
a single XPath value.  It's an error for value nodes to appear
anywhere in the result tree.

A saxon:function element augments the "function library" component
of the initial context; a saxon:return element denotes an
XSLT instruction which returns a list consisting of a
single value node.  To evaluate a function defined by
a saxon:function element, instantiate the list of instructions
in its body (i.e., the denotation of the content of the referenced
element).  If the result is an empty list, then the function
returns an empty string; otherwise the result must be a list
consisting of a single value node, which determines the
return value of the function.

(A minor but potentially useful variation of this definition
would be: "[...] the result must be a list whose _first element_
is a value node, which determines the return value of the function."
This would yield the intuitive "return instructions cause
the function to terminate early" semantics discussed earlier
in the thread, and would give a sensible meaning to
<saxon:return> inside <xsl:for-each> or even <xsl:template>.)

'saxon:assign' on the other hand would involve a much bigger change
to the XSLT semantics, but I think it's doable as well.
It _would_ require major surgery on the XSLT Recommendation, though;
there's a lot of stuff which is currently unspecified
(because it doesn't need to be at present!) that would need to
be explicitly stated before mutable variables would make any sense.

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.


--Joe English

  jenglish@xxxxxxxxxxxxx

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


Current Thread