[
Lists Home |
Date Index |
Thread Index
]
Jeni Wrote:
>
> 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.
>
No, thats not what I mean. In my system, the annotations point [via
XLink-like HREF] to the nodes they annotate.
>
> >> 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?
>
Mostly commercial reasons, I still like the annotation axes better, but just
don't see a way to make it fly in my projects time frame. Usually, I can
use leading edge, but not bleeding edge components. On the other hand, if I
see something bleeding edge that can be vetted against leading edge
components without a great deal of cost, then I can probably use it.
> 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>
How is the annotation linked to what it annotates in your examples?
> 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.
Actually, I am somewhat interested in where they came from. In our library
of medical records, we have annotations on sentences attesting to codes that
are justified by that sentence. I would want to identify the source of the
code [one of several software modules, human review, et cetera]. That's
actually not terribly difficult. If I can get to the element, then I can
get to it's parent or ancestor which could tell me that information.
<<attachment: winmail.dat>>
|
