Re: FXPath v0.3 + SAXON Implementation

Hi David,

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

Ah, very good point.

So actually there's a limitation with both fx:template-function and
exsl:function that I missed: you can't use one function to produce new
attribute or namespace nodes. But that's easy to get round if you
produce elements with those nodes on instead, and use fx:define (or
exsl:function returning a node set) to isolate the nodes you actually
want. Probably I should think up a use case to demonstrate that.

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

I don't know either. Most scenarios that I could think of involved
getting bunches of nodes before and after a particular node in sorted
order, for example to provide navigation around a document, which
might well be uncommon. So for example, I have a load of keyword
elements in no particular order and I want to apply templates to (or
create a key that uses) the ones that come before a particular
keyword.  They all seem a bit of a stretch to me, but you never know
what people are going to come up with.

Cheers,

Jeni

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



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