Re: Designs for XSLT functions (Was: Re: [xsl] RE: syntax sugar for call-template)

Subject: Re: Designs for XSLT functions (Was: Re: [xsl] RE: syntax sugar for call-template)
From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx>
Date: Wed, 21 Feb 2001 14:34:45 +0000
Hi David,

>> > It would by syntactically XPath 1.0 but not semantically, so you can
>> > still not call it XPath 1.0. And if you are considering leaving the
>> > pure XPath 1.0 track it would be a small step implementationwise to
>> > have another syntax, though the particular syntax isn't that
>> > important here I think. One thing to consider though: if it by
>> > definition doesn't behave like an extension function, it probably
>> > shouldn't look like one.
>> Well OK, and I think that this is a good argument for not restricting
>> ourselves to only variables in the body of exsl:function.
> Sorry, you lost me there, how do you mean these things are related?

If introducing exsl:if() with useful behaviour (i.e. the ability to
not evaluate one of its arguments) breaks the semantics of XPath, then
we are left with two choices:

1. we introduce a way of doing conditions in eXPath
2. we use XSLT constructs to give us those conditions

With the second option, we are not restricting ourselves to only
variables (aside from exsl:return and xsl:param) in the body of
exsl:function - we are allowing xsl:if and xsl:choose as well.

I was working from the premise that we cannot extend XPath
syntactically aside from introducing extension functions and that we
cannot extend it semantically at all (based on your argument quoted
above). Working from that premise, option 2 is the only viable option.
I know you disagree with the premise.

>> Personally, I think that any kind of extensions to XPath are beyond
>> what can be legally done to extend XSLT. I am not sure that (other)
>> implementers would respond positively to the idea of having a
>> different, XPath-like syntax within a particular attribute in an
>> extension function.
> What do you mean by legal?

I mean supported by the Rec.  The Rec. only talks about extending
XPath and XSLT through extension functions and extension elements, not
about extending XPath through new constructs.

> My proposal is certainly legal XSLT 1.0.


> In fact, if we loosen the concept of legality a bit I could argue
> that changing the constraints on XSLT instuctions would be illegal
> unless you put them in a new namespace. (Strictly speaking they are
> legal since there are no constraints what so ever on the contents of
> an extension or top level element). What I'm saying is that if you
> changed your proposal to use exsl:choose, exsl:for-each etc then
> this would be better since then you would be defining a completly
> new languge to deal with node set (and other primitive XPath types)
> functions. This instead of trying to retrofit XSLT instructions into
> something they were not designed for.

I agree that we must not change the definitions of existing XSLT
instructions. I think that it will be possible to define exsl:function
and exsl:result in such a way that the only constraints are expressed
in terms of what they can contain and what they can be contained in.
(Or more likely what they can 'instantiate' - dynamic constraints will
be easier to express than static ones.) We shouldn't have to add any
constraints to any existing elements or functions.

Of course I may be wrong: perhaps I should just start trying to write
it and see if you're right.

>> The main reason that I disagree with your proposal is that I am
>> *certain* that it *doesn't* cover all the possible cases.
> Since you, in my opinion, haven't got even halfway setting the
> semantics of you proposal I think claims for full coverage are too
> early to make. (well you didn't explicilty claim it, I just sensed
> an implicit comparison).

I was absolutely not claiming full coverage for anything.  In your
mail you'd said:

  > I'd say it isn't trivial to know that we've covered all the
  > possible cases.

and I completely agree with that. However, we *can* tell when
something *doesn't* cover all possible cases - we just find one
exception. That's all I was doing.

> I suggest that you start with a small, clean and well defined core.
> Use it for a while. Discover what's missing. Design equally clean
> and well defined improvements and add them to your language. Going
> for the big bang directly can be devastating.

I have a lot of sympathy with this approach. However, it's possible to
be *too* cautious, and make a decision early on that then limits what
we can do later or to generate so small a core of functionality that
it's unusable in all but the very simplest cases and therefore fails
to get support. We are rapidly building up a set of use cases for the
kinds of functions that we'd like to be able to implement. I think
that our version 1.0 should be able to cover them.

> It has been said earlier on this thread that one purpose of this
> effort is to explore new functionality that could possibly make its
> way to new versions of XSLT and XPath. Maybe I'm blind, but I just
> can't see the logic in evaluating new possible extensions to XPath
> by trying to implement them with retrofitted XSLT instructions. For
> the XSLT part it's OK, but for XPath it just doesn't make sense.

I agree (if I've interpreted what you're saying correctly). When we
are speculating about new constructs for XPath, there is absolutely no
point in saying that the new XPath has to be backwards-compatible with
the old XPath.

I know that your argument is that an attribute on an extension element
is open territory - it doesn't have to be constrained to XPath syntax.
That's indisputable so I won't dispute it.

So there are two valid routes that we can take to achieve the
functionality that we want to achieve:

1. introduce extensions to XPath syntax for attributes on extension
2. restrict ourselves to introducing only extension elements and

In both routes, there are further decisions to be made. To get the
kinds of functionality I have use cases for with user-defined
functions, we need: a conditional construct, a means of changing the
context node and then calling key() or id() or whatever, and a way of
comparing strings. (At least.)

[ My preference would be for the second route because I believe that
  it's more likely to get implementer support and I think that it will
  lead to less confusion. People are generally OK about accepting that
  a particular element is not allowed in a particular context. A
  particular XPath syntax being allowed or disallowed is somewhat
  different. But we can both speculate on that 'til the cows come home
  - it's hard to get evidence either way. It would be good to get some
  feedback from other implementers on the possibility of extending
  XPath other than through extension functions.]

Anyway, I don't want my personal preferences to affect the space of
designs that we examine. We're looking at the second route in other
parts of this thread - so let's look in detail at the first route as
well. I'm pretty sure that all of those are covered in the
requirements spec for XPath 2.0, and I think it's fair to say that
there are multiple plausible designs for each of them, some of which
involve introducing new syntax into XPath or changing the semantics of
the old syntax.

So let's discuss some possibilities...

1. conditional construct

a. test ? true : false

   Note: possible problems with : being used - have to make sure that
   it has spaces either side to distinguish between it being used in
   this construct and in a name

b. test ? true ! false
c. IF test THEN true ELSE false
d. #if test #then true #else false
e. if(test, true, false)

   Note: as discussed, need to change the semantics of when arguments
   in functions are evaluated with this last option

2. changing context node for id(), key() & unparsed-entity-uri()

a. document(doc, base)/id(identifier)
b. document(doc, base) -> id(identifier)
c. id(identifier, doc, base)
d. id(identifier) IN document(doc, base)
e. id(identifier) #in document(doc, base)
f. WITH document(doc, base) id(identifier)

3. comparing/sorting strings

a. compare-strings(string1, string2)
b. string1 > string2  (etc.)
c. sort(string1, string2)
d. sort(nodes, ...)

Any comments on any of these?

> It seems like many of you think XPath is untouchable, holy ground,
> whereas XSLT is not. I don't really see why you are making that
> distinction. Albeit we would have to go over an extension function
> call to test new XPath constructs from arbitary places in our
> stylesheets, this doesn't justify not implementing XPath extensions
> in XPath rather than in XSLT instructions. (The function call is
> necessary since the experimental XPath may only appear as a
> descendant to an extension or top level element)

In other words we need a equivalent of function-available() or
element-available() that would tell us whether a particular XPath
extension were available on the particular processor?

I think that system-property() would be ideal for that.  We could


for example, which could return true() (or a non-empty string) if it
was supported.

>> As you imply, I think we'll probably have to agree to disagree on
>> this. Personally, I find messing around with extension elements more
>> acceptable than messing around with XPaths.
> Well, sorry, the mutal-disagreement-escape won't stop me from
> arguing :-)

Nor me.  If nothing else it's a useful way of exposing our hidden
assumptions and prejudices.



Jeni Tennison

 XSL-List info and archive:

Current Thread