Re: Re: FXPath - A comment on EXSL

Hi Jeni,

> 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. If I count them as instructions I must clarify that the result
of instantiating them, which is always empty, is not added to any RTF
(there isn't one to add them to). Or I could just change the namespace.
If I don't count them as instructions, it would be enough to specify
their scoping rules. In any way, it has to be clarified.

> 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.

> I think I'm going to change exsl:return to exsl:result for the next
> draft, as discussed with Uche, so what about this instead:

[ snip (new processing model described) ]

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.

Cheers,

</David>

David Rosenborg
Pantor Engineering AB



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