[
Lists Home |
Date Index |
Thread Index
]
Uche wrote:
Kieth had written:
>> This is actually something similar to what I intend to implement
>> over an XML Repository [probably Xindice].
>>
>> We have a requirement to be able to; given a node, find all
>> annotations [of a particular type or matching certain criteria], on
>> that node.
>>
>> While I want to be able to express this as an Axis in the XPath
>> object model, I've got a few problems with that:
>>
>> 1. How do I specify the Annotation context for the annotation axis.
>> Our annotations are stored as standoff annotations, and to
>> complicate things further, may apply to either a single document or
>> a collection of documents.
Keith: Do you mean how do you get *back* from an annotation to the
node from which you got it? That's a different problem, I think -- I
don't think that for every axis there must necessarily be an axis that
takes you in the reverse direction.
>> 2. It's a heck of a lot easier to create a new XPath function in
>> existing public domain XPath implementations than it is to change
>> the parsing and execution model.
>
> This is very true, and another key reason with my uneasiness with
> extension axes.
But this is why I'd like to see XPath-NG defined differently. Rather
than listing all the possible axes, you'd have:
AxisName ::= QName
and then it would be up to separate modules to specify useful axes for
that module.
I can certainly understand the reluctance to go with axes if you're
working without the boundaries of XPath 1.0, but if we're reaching for
XPath-NG then why not?
>> 3. The association between a node and it's annotation isn't totally
>> clear. Does a node have an annotation if the annotation directly
>> specifies the node? That's easy -- yes. Does the node have an
>> annotation if it's ancestor has an annotation? That's not very
>> clear, although I lean towards yes. So, then I really want to axes,
>> the annotation:: axis which returns the former, and the
>> annotation-closure:: axis, which returns the latter.
>>
>> This became to complicated for what I required in the short run,
>> so, I've made a design decision that we'll probably have to go the
>> function route.
>>
>> What I came up with for an API was:
>>
>> node-set extension:annot(node-set source [, string tag])
>>
>> Returns the node-set consisting of all annotations on source. If
>> tag is supplied, then only those annotations whose element name
>> matches it will be returned. The value of tag is a list of tags to
>> be included in the result, separated by white space or | symbols
>> [NOTE: What I really wanted to pass in to this function here was a
>> relative location path so that I could optimize the selection].
>
> Looks good, and pretty much what I've proposed, but I still wonder what the
> form is of annotation nodes. Are they the data model equivalent of
>
> <annotation id="type">integer</annotation>
>
> for example?
I'd prefer them to be elements identified by name. For example:
<psvi:type-definition>xs:integer</psvi:type-definition>
<xforms:required>true</xforms:required>
>> So expr[extension:annot(.,"tag")] returns anly those nodes which
>> have a <tag> annotation, and
>> expr[extension:annot(./ancestor-or-self,"tag")] selects a similar
>> set, save that the annotation can be on the nodes or its ancestors.
>> I didn't feel it necessary to have a function that automatically
>> applied the ancestor-or-self notion simply because the number of
>> ancestors is going to be small [3-7] for any given node I have to
>> apply this to in our system, however, I may change my mind once I
>> start implementing.
>>
>> Of course, I still haven't figured out how to set the context up
>> yet for annotations, but still I have a few weeks to do some more
>> design.
>
> I think that once we figure ou the data mnodel for annotations, we
> can come up with a context analog. For example, if we go with my
> annotation element above, then we might say, roughly that such
> elements are top-level elements in a separate, special annotations
> document which contains all the annotation nodes for a given XML
> source document. The annotations() function could then be defined as
> shifting the context *as if* it were an axis which selected a set of
> annotation nodes as the new context node list.
Hmm... Do you think that it's too loose to leave it up to the
particular annotation to determine what other structure might be
defined around the element node that's returned through this function?
It would be useful if you could use an annotation that gives you a
hook into the PSVI as a starting off point for navigating the PSVI,
for example. Or an annotation might be standalone, in its own document
for all intents and purposes. What matters is that the annotation
function/axis returns a bunch of element nodes -- I don't think that
we really need to care where they come from.
> Then again, as I think of it, this may also introduce implementation
> difficulties. In 4Suite, this would work because extension functions
> receive a mutable instance of the context. I expect this is not the
> general case. Do other processors pass the context to extension
> functions by value rather than reference?
I don't understand why this is required. Can you explain a bit more?
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
