Re: [xsl] FXPath v0.3 + SAXON Implementation

Subject: Re: [xsl] FXPath v0.3 + SAXON Implementation
From: "David Rosenborg" <david.rosenborg@xxxxxxxxxx>
Date: Wed, 7 Mar 2001 17:45:57 +0100
Hi Jeni,

> It seems to me that the natural progression, if XSLT 1.1 does
> eventually include xsl:script, is to have FXPath as one of the
> possible languages.  This would involve adding a bit more syntax to
> the FunctionDefinition expression, to enable it to give the name of
> the function without a surrounding fx:define and perhaps to isolate
> particular functions to make it easier to parse a load of these
> functions in a single element.

Yes, that's defenitely a possibility. And I think a semi-colon (';') could
do the job of terminating a function, just as it terminates expressions
in an enumeration of variable bindings.

> I really like the idea of using an attribute on fx:template-function
> to indicate the type of value that the contained RTF should be coerced
> to. I hope you won't mind if I add that possibility to the set of
> options for exsl:function?

No problemo.

> I think it would be very useful, though, if you *could* coerce to a
> boolean value by converting the result tree fragment to a string and
> then to a boolean.  So if any text was generated within the template
> function, it would result in true(); if no text were generated, it
> would result in false().

Actually, I had that in my spec at one point, but I took it out since
I thought it was inconsistent with other coercion: it would be
a two step thing: boolean (string (<the-RTF>)). I wanted
it to be consistent with first declaring a variable with an RTF
value and then applying a single coercion function to
that value. However, I admit it would be convenient.

> Actually, the structure of fx:template-function is pretty much the
> same as a named template - the semantics of the parameters are
> different, but otherwise it's the same. Perhaps, rather than
> introducing a new element, it would be simpler to add an extension
> attribute, fx:result-type, to xsl:template to allow it to be called as
> a function (provided it has a name, of course). I like that option
> because it makes it a easier to make utility function/templates
> available without repeating lots of code.

Yes, I thought about it too. My only concern then would be
the base URI and content constraints (no attributes on the root node etc) of the RTF.
No base URI or content constraints are defined for xsl:template. And I don't like
the idea of having different constraints depending on how you invoke your template.
The constraints should be statically scoped in my opinion. And you could not let the
occurence of the fx:result-type attribute affect static constraints, since this would
break the extension rules for XSLT.

> (I'm thinking in particular of
> functions involving returning node subsets based on sorted position,
> which exsl:function as it currently stands also has problems with).

One way of dealing with this in a declartive way would be to introduce a reordering operator
to predicate expressions. However, I don't know if the scenario is common enough to
motivate such a thing. 

It could look something along the following lines:

//person >>(last-name) [1]                  -- The first person in alphabetical order

Where '>>(...)' is the reordering operator. The operator could appear anywhere among the predicates:

//person [title = 'manager'] >>(age, data-type ('number'), direction ('descending')) [1]             -- The oldest manager

But maybe this is sliding too far into the land of XQuery ...



David Rosenborg
Pantor Engineering AB

 XSL-List info and archive:

Current Thread