[
Lists Home |
Date Index |
Thread Index
]
Jeni,
> Hmm... I think I disagree because I can imagine it might sometimes be
> useful to get the annotations of the same kind from a whole bunch of
> nodes. For example to answer the question "Does this element have any
> attributes with a type of xs:ID?" you might use:
>
> @*/annotation::xsi:type = "xs:ID"
>
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. I suppose you could establish a
convention so that annotations for attributes, although really child
elements of the owning element, work in the xpath expression as if they were
children of the attribute, sort of like pseudo classes in css. I think that
would be pretty confusing, though.
I take it, though, that you would like to do the same thing for annotations
of a set of descendant element nodes?
> I guess that I'm in favour of using axes rather than functions
> whenever you get a bunch of nodes returned by applying some process to
> a context node. But if Uche's talking about just adding extensions to
> XPath 1.0 then sticking with functions is a better idea.
>
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?
Cheers,
Tom P
|
