[
Lists Home |
Date Index |
Thread Index
]
Hi Tom,
>> 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.
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".
An XPath like:
@*/annotation::xsi:type
says nothing about *children*. It just says "get the annotations
associated with each attribute".
> 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.
Yes. Adding annotations to the data model would require... the
addition of annotations to the data model :) The 'annotations' of a
node would become another property, in the same league as 'name' and
'namespace-uri' and 'attributes'.
> I take it, though, that you would like to do the same thing for
> annotations of a set of descendant element nodes?
Of course. On any set of 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?
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.
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.)
Cheers,
Jeni
[1] http://www.lmnl.org/
---
Jeni Tennison
http://www.jenitennison.com/
|
