Re: Re: FXPath - A comment on EXSL
Hi David, >> 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 --> <xsl:variable name = qname select = expression> <!-- Content: template --> </xsl:variable> 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 terminology. 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. Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/ XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format