[
Lists Home |
Date Index |
Thread Index
]
> 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.
> 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.
> 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?
> 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.
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?
--
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
Apache 2.0 API - http://www-106.ibm.com/developerworks/linux/library/l-apache/
Python&XML column: Tour of Python/XML - http://www.xml.com/pub/a/2002/09/18/py.
html
Python/Web Services column: xmlrpclib - http://www-106.ibm.com/developerworks/w
ebservices/library/ws-pyth10.html
|
