[
Lists Home |
Date Index |
Thread Index
]
Hi Keith,
>> >> 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.
Right, so you've got the problem where you have a source document and
a bunch of annotation documents, and the elements in the annotation
documents point to the source document but the source document doesn't
point to the annotation document, correct?
What I had in mind (and I realise that you might not be able to/want
to do this for your project, but I'm thinking in terms of XPath-NG)
was that the nodes in the source tree generated from the source
document would contain a 'annotation' property that would hold
references to element nodes that acted as annotations on the source
tree.
For you to implement that from your setup, you'd need to do something
like:
1. create a DOM from the source document
2. create DOMs from the annotation documents
3. go through the annotation document DOMs and, for each annotation
A, identify the source node to which it refers, N, using the
xlink:href attribute or some other means as appropriate.
a. add A to the list of annotations on N
b. add N to the list of annotations on A
This gives you pointers from the source node to the annotation nodes
and back again, so that you can travel in both directions.
>> >> 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.
Sure, sorry -- I was really asking Uche. I quite understand that for
your project you have different design considerations than XPath-NG
does.
>> 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?
Through a property on the node in the source tree (e.g. the same way
that a node is linked to its parent or an element to its attributes).
>> 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.
That's actually precisely what I had in mind :) When I said "we don't
care where the annotation comes from" I meant "we should not specify
where the annotation comes from". Rather than taking the annotation
elements and creating a new document from them, we should just jump to
those annotations elements in whatever context they have. Then you can
travel from the annotation to the parent/ancestor or whatever.
By the way, I'm a little concerned that we might be using 'annotation'
to mean different things. I've been using it to mean "Infoset
augmentations" -- things that aren't part of the XPath data model but
that we want to get access to -- whereas I think that you actually
*mean* "annotations", at an domain level. In that case, I think you
can do something like:
<xsl:variable name="annotation-doc"
select="document('annotations.xml')" />
<xsl:key name="annotations" match="annotation"
use="generate-id(document(@xlink:href, .))" />
<func:function name="my:get-annotation">
<xsl:param name="node" select="." />
<xsl:for-each select="$annotation-doc">
<func:result select="key('annotations', generate-id($node))" />
</xsl:for-each>
</func:function>
(Where 'func' is associated with http://exslt.org/functions.)
To create a my:get-annotation() function that will return the
annotation element that references a particular node. Assuming that
you have a URIResolver that can resolve the URIs that you're using
into nodes, that is.
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
