Lists Home |
Date Index |
>> Personally I'd use qualified names rather than URIs for the
>> "lookup", but that's because I envisage getting to annotation
>> information through an axis rather than through a function and
>> because QNames are easier to write than URIs. Perhaps a function:
>> that returns a node set, and let the user use XPath mechanisms for
>> doing the lookup within that node set?
> I would say the function, because I see annotations as closely tied
> to nodes that they annotate. If we only had an axis, we could get
> annotations but it would be harder to tie them to their nodes. That
> would not be so if annotation::* only returns annotations associated
> with the context node, but that seems too limited to need an axis.
> Otherwise I like the idea of an axis but think that there should be
> a function anyway.
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"
of course you could do the equivalent with:
@*[annotations(.)/xsi:type = "xs:ID"]
but then you could do the equivalent of:
if you were only interested in the first foo element.
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.