[
Lists Home |
Date Index |
Thread Index
]
Jeni,
> > At this point I am wondering how you could annotate attributes,
> > since your xpath expression says to get annotationsthat are children
> > of any attribute but attributes cannot have any children.
>
> No it doesn't. An XPath like:
>
> @*/child::xsi:type
>
> would say "get the child xsi:type elements of each attribute". An
> XPath like:
>
> @*/parent::*
>
> would say "get the parent element of each attribute".
>
I see I could have thought out that wording some more, couldn't I? Say
about another two hours! I was thinking about annotation elements to be
about the only way to hold annotation information about the attributes, and
those elements would be what you would be getting back from the expression.
Not what I wrote, though, eh?
> > I am interested in having the function more than the axis, but I
> > would like an axis too, if we can work out just what it would mean.
> > Could there be an extensible way of adding new axes as well as
> > functions? That would be a real contribution to xslt 1.0+ if it
> > would turn out to be feasible. I see the processor handing the
> > extension code a set of nodes and getting back a set of nodes. With
> > the right api, the extension could perhaps use some of the optimized
> > code from the main processor for traversal, etc. I suppose this must
> > have been discussed to death when exslt ws getting started?
>
> No, but it's something that we've been discussing here more recently
> :) I'm quite keen on having swappable-in axes (though this is
> partially for nefarious motives that Eric van der Vlist has uncovered
> -- I want to be able to easily extend XPath to deal with LMNL [1]
> structures). I'm less sure about user-defined axes, but that's mainly
> because I'm worried about how the parsing would work; but on that, I
> guess that if you can deal with user-defined functions then you can
> deal with user-defined axes, right?!?
>
> The main problem is that any of these changes require some fairly
> fundamental changes to the XPath data model, so these aren't things
> that we can just plug on to XPath 1.0. When we set up EXSLT it was an
> explicit aim *not* to go outside the XPath 1.0 data model and the
> allowed set of extensions that you could make to XPath/XSLT 1.0.
> That's why we don't have an if() function, for example. I, at least,
> was keen on EXSLT to be a proving ground for new functions and
> elements that could be rolled into future versions of XSLT.
>
Yes.
> I'd like to keep EXSLT in that role, rather than making it a
> competitor for XSLT 2.0, but that doesn't mean that there isn't a home
> elsewhere for XPath-NG. (Plus of course it may be that my co-managers
> feel differently about how EXSLT should develop.)
>
EXSLT+, perhaps?
Cheers,
Tom P
|
