This is the mail archive of the
mailing list .
Re: Re: FXPath - A comment on EXSL
>> Then shouldn't you change xsl:param and xsl:variable to fx:param
>> and fx:variable? Aren't those elements being instantiated to get
>> the behaviour you want from them?
> Yes, maybe I'd have to put them in another namespace. More
> important: I should clarify that the content model (xsl:param*;
> xsl:variable*, #PCDATA) doesn't constitute a template. Whether I'd
> have to put the variable-binding elements in a new namespace depends
> on whether you count them as instructions or not. The XSLT spec
> isn't fully clear on this point as I see it.
The XSLT Rec. categorises xsl:variable as an instruction:
<!-- Category: top-level-element -->
<!-- Category: instruction -->
name = qname
select = expression>
<!-- Content: template -->
It doesn't categorise xsl:param as an instruction.
But as far as I can tell the important thing is whether the
surrounding element of an instruction instantiates its content (in
which case, presumably, the instruction is instantiated) or not. So as
long as you don't say anything about the content of fx:function being
instantiated, then you're probably OK.
>> I think I don't understand the technicalities of the term
>> 'instantiation'. I thought it meant 'running' a particular
>> construct to make it do the thing that it does. So you
>> 'instantiate' an xsl:variable element to make it assign a value to
>> a variable.
> By instantiation I mean 'running' XSLT instructions and getting an
> RTF as the result.
Ah. OK, no wonder we're having problems. Reminds me of my PhD thesis -
the source of many disagreements being rooted in mismatches of
I think of the instructions like xsl:for-each and xsl:choose as being
conceptually different from the ones like xsl:element and
xsl:value-of. Whereas the latter generate result nodes, the former do
not (of themselves - their content might, but they don't). I'm very
willing to admit that this might be an inaccurate conceptual model of
XSLT instructions according to the Rec, but this is one reason why
I've had trouble understanding your arguments.
> Still I don't see how the value of the exsl:result can propagate out
> of the XSLT instructions without you redefining the processing
> model. You cannot store it in the RTF without changing the
> definition of RTFs, so it has to take some kind escape route out of
> the instructions. Again this can of course be implemented, it just
> seems unnatural and non-XSLT-ish.
I now understand what you mean, and agree that given that all
instructions are instantiated to give RTFs then the instantiation of
the XSLT instructions in exsl:function must produce an RTF and
therefore an exsl:function element that is based on instantiating XSLT
instructions cannot produce anything other than an RTF without
changing the XSLT processing model.
Of course it's not going to stop me from continuing to work on
user-defined functions in EXSLT, but it will definitely help me to
give a more balanced account of the implications of its design.
Thank you for being so patient and good humoured throughout this
discussion. I've found it very enlightening.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list