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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Functional programming in, David Rosenborg | Thread | Re: [xsl] Functional programming in, David . Rosenborg |
Re: [xsl] browsers with XSL capabil, Larry Garfield | Date | Re: [xsl] browsers with XSL capabil, Robert Koberg |
Month |