[xsl] Re: FXPath - A comment on EXSL

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