[xsl] Re: FXPath - A comment on EXSL

[Jeni Tennison <mail@xxxxxxxxxxxxxxxx>]

Hi David,

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! :)

> The purpose of this document is to outline an alternative approach
> to writing extension functions in XSLT. The FXPath approach is based
> on XPath where as EXSL is based on XSLT instructions. The basic idea
> is that functions dealing with primitive XPath types are better
> implemented in a language close to XPath rather than by retrofitted
> XSLT instructions.

It's good to see such a detailed proposal of changes that could be
made to XPath.

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.

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.

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.

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.

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.

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

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?

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?

There's a typo in doc-helper:key in that the node elements created in
the RTF don't have an id attribute on them that they need. They should
be:

  <node id="{generate-id()}" />

There's also one in Section 5 where you're defining PrimaryExpr -
FuntionCall should be FunctionCall.

Finally, I'm interested that you didn't go for some of the XPath 2.0
possibilities, especially document(...)/key(...). Any particular
reason?

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/



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