Subject: [xsl] Re: FXPath - A comment on EXSL From: "David Rosenborg" <david.rosenborg@xxxxxxxxxx> Date: Wed, 28 Feb 2001 15:45:02 +0100 |
Hi Jeni, > I'm glad to hear from you again - you've been quiet for so long that > my auto-mailbox-cleaner has got rid of all your mails! :) Fortunatly, not everything in life is XML :-) > I think it raises philosophical questions about the balance between > XSLT and XPath. One of the aims of XSLT was that it be written in XML > - that it should use elements and attributes for its programming > constructs. But if *everything* was in XML... well there'd be *even > more* objection to XSLT's verbosity! So some of it was moved into a > more compact, non-XML syntax - XPath. 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. > Now I don't think that the line was drawn at the right place: there > are some things that are only possible to express in XSLT that I think > should be expressable using XPath, notably conditional expressions. > But personally, I think that setting variables and doing recursion are > beyond what XPath should be doing. (I can't, though, come up with > arguments that aren't based on 'gut feelings' or 'slippery slopes'.) > Presumably the scope of XPath is something that will be revisited with > XPath 2.0. The scope of FXPath is only to define a superset of XPath sutiable for extension function implementations. I don't mean that the extensions are necessarily applicable or feasible for XPath use in general. 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. > Anyway, leaving that aside, I still don't understand the > 'anti-retrofitting' argument. The EXSLT document has nothing in it > that the syntax or semantics of any XSLT elements as far as I can tell > - everything's expressed in terms of where exsl:return can be used and > what exsl:function can contain. I don't understand how this really > differs from what's being done with XPath in FXPath - why is using > XPath (and changing some basic definitions that it uses) termed > 'supersetting' whereas using XSLT (without changing any of the > definitions in XSLT) termed 'retrofitting'? It's probably some > technical use of the term that I'm not familiar with. 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. You could argue that EXSL does not change the behaviour of XSLT instructions, but then the exsl:return must act as an escape function. While this is feasible in most imperative languages like Java or JavaScript, it doesn't rime well with the current processing model of XSLT which has it roots in, believe it or not, declartive languages like Scheme (via DSSSL). In FXPath I don't have to trick XPath to deal with types it wasn't designed for. I don't change the processing model or semantics for the XPath subexpressions but I admittedly extend the syntax in a recursive manner. > On to more practical comments... In general, the mixing of XSLT > elements (xsl:param and xsl:variable) with text within fx:function > seems a little weird to me. I can see that you need xsl:param and > xsl:variable to create RTF variable values. Can you explain why you > went for having the rest of the fx:function element holding text > rather than placing the FXPath within an attribute value on fx:return > or something similar? The latter would seem to fit more with the > pattern of how XPaths are used in XSLT. This is a controversial one and I admit it isn't kosher but I wanted to try the idea. Maybe it's not a good idea, I don't know yet. The main approach was that since the whole function should be implemented in FXPath, why stuff it inside an attribute just for the sake of it? As I see it, it has two positive effects not putting it inside and attribute: there is less risk for string quote conflicts and you can add inline comments. However, these arguments are not strong, and if it appears important for consistency that a FXPath lives inside an attribute value then we can put it there. > I think that you should make explicit that the scope of the variables > defined within an FXPath expression is that FXPath expression > (assuming that it is?) Also, I think you should make it clear that a > VariableExpr returns the value of the OrExpr. Yes, my spec is still underspecified, its a version 0.1 ... > With the keywords in IfExpr and Reduction, I wonder whether it would > be a little easier for implementors and authors if they were given > names that absolutely could not be element names? All that would > involve is adding a '#' at the beginning of each of them. For example, > if I had an element that was called 'reduce' then this would currently > be mistaken for the keyword and presumably give an error. If you don't > make this change, perhaps some words on tokenisation might be in > order, as there are in the XPath Rec > (http://www.w3.org/TR/xpath#exprlex). 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. It's the same situation as in function calls: true -- Selects the element true true () -- The value true if -- Selects the element if if $test -- The start of an if expression if ($test) -- Here is a slight ambiguity, but since there is no if function it can be easily resolved Adding '#' would be mostly for visual guidance, but in my opinion it would clutter the language. > The Reduction Expression is sweet - I particularly like the way it > indents nicely ;) It gives a nice shortcut to common functionality; > of course it can't handle all recursion cases, as demonstrated in > gen:range, for example, but it does most very simply. I guess it has > some similarity to the for loops that are generated by processors that > optimise tail recursion? Yes, the reduction expression is convenient. It's not strictly needed since it could be replaced by recursive functions, but in my opinion it falls on the right side of the 80/20 line. Yes, it's implementation complexity is on par with for loops and it can easliy be implementated to run in constant stack space. > I really like the fx:required function as a way of indicating that a > particular parameter is required. Would you mind if I included that > in the next version of the EXSLT document? I don't mind. > There's a typo in ... Thanks, I'll fix them right away. > 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. Loosening the constraints on location steps to allow function calls at arbitrary places would help a lot here. This is a natural step (and fairly easy to implement in my opinion) to go further. The first version of FXPath only tries to outline the general idea of writing user defined extension functions in a XPath fashion. There's a lot more to be done. Cheers, </David> David Rosenborg Pantor Engineering AB XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[xsl] Re: FXPath - A comment on EXS, Jeni Tennison | Thread | [xsl] Re: FXPath - A comment on EXS, Jeni Tennison |
[xsl] Latest version of MSXML?, Gavin Landon | Date | RE: [xsl] Is XML to CHTML Transform, Jarno Elovirta |
Month |