Subject: [xsl] Re: FXPath - A comment on EXSL From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx> Date: Wed, 28 Feb 2001 19:03:17 +0000 |
Hi David, > Fortunatly, not everything in life is XML :-) Wow, we really are on different planets ;) > Yes, and I think user defined extension functions sits almost right > in the middle of the two. I think that's why we can find sensible > arguments for choosing either syntax for this purpose. However, as > you know, I think most of the extension functions will deal with > XPath types and should therefore be implemented in an XPath fashion. I think that this means that you anticipate that most functions won't produce RTFs/generate new nodes (something that I'm inclined to agree with, although interestingly two of the use cases [gen:range and gen:tokens] do). > Now, about variables: I don't think it's too awkward for a language > that have the notion of variables to also have a way of defining > them. It depends how you view XPath. I think I really see XPath as an expression language for use *within* another language (i.e. XSLT). To me, variable values are part of the XPath context, along with a function library, the context node and so on. They're things that are set at the next level up in the application and 'passed in' to the expression. A bit like stylesheet parameters, if you like. But I guess this might be something that applies to XPath but doesn't apply to the superset that is FXPath. > The result of instantiating a set of XSLT instructions is a result > tree fragment. As I see it, you change that definition in EXSL by > allowing arbitrary XPath types to be the result of such an > instantiation. That's a fair point, but what we're doing with exsl:function/fx:function is a bit weird anyway. I think that we're both doing basically the same thing: the result of instantiating fx:function should be a result tree fragment, but you're returning something else from it. If you placed your FXPath in an attribute value (where it belongs! ;) then your fx:return would be 'breaking the same rules' as exsl:return. Without fx:return, then by rights fx:function should just be producing a text node! I don't really see the distinction between the two approaches on this front, but perhaps it's because I read the above before I read: > You could argue that EXSL does not change the behaviour of XSLT > instructions, but then the exsl:return must act as an escape > function. Ah, here you're talking about using exsl:return within xsl:when, xsl:otherwise and xsl:for-each, with the 'return' returning (escaping) from the function. I agree that the processing model of XSLT doesn't include this kind of functionality (and probably shouldn't). The way I view it is that the instantiation of the content of exsl:function generates an RTF consisting of one (or more) exsl:return elements. The first of the exsl:return elements is taken, and its select attribute is evaluated to give the result of the function. Perhaps that's still not acceptable. > Yes, my spec is still underspecified, its a version 0.1 ... Oh, so's "mine" :) These aren't criticisms, they're just comments on where I think you could improve it. I'm looking for the same kind of comments on the EXSLT one. > Yes, tokenisation should be mentioned. If I've not overlooked > something, the FXPath grammar can be parsed with a single token > lookahead. This is what's currently needed for XPath 1.0. OK, great. So if you (or future XPath extenders) were to introduce new keywords then it would just involve making sure that they don't conflict with existing function names (and presumably operators). >> Finally, I'm interested that you didn't go for some of the XPath >> 2.0 possibilities, especially document(...)/key(...). Any >> particular reason? > > One step at a time :-) The doc:key function looks messy both in > FXPath and in EXSL. I agree about doc:key. Part of the reason I included it as a use case is that it would look so much nicer if xsl:for-each were allowed within exsl:function. I've just banged my head against getting nodes from other documents using key() so many times that I really want to see a better way of doing it as soon as possible. Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/ XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[xsl] Re: FXPath - A comment on EXS, David Rosenborg | Thread | RE: [xsl] Re: FXPath - A comment on, DPawson |
Re: [xsl] 2.1 Must Allow Matching o, Uche Ogbuji | Date | RE: [xsl] what is biztalk ??, Max Dunn |
Month |