[
Lists Home |
Date Index |
Thread Index
]
Hi Uche,
>> 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.
>
> Yeah. As I give it more thought, I think that extension axes need
> not be as big a deal as I first thought. It would certainly involve
> a refactoring of 4XPath, and would move axes from the grammar to the
> symbol table code, but it's feasible, and besides the inevitable
> loss of performance does not really harm the architecture.
Cool :)
>> 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>
>
> Fine with me. I guess that means that there have to be namespace
> nodes added for the annotation nodes somehow.
Well, under this scheme, the "annotation nodes" are just element
nodes, so they'd deal with namespaces in the same way as other element
nodes. It's just that they're accessed through a different axis and
don't come from the source document itself.
(There are lots of issues surrounding namespace nodes in XPath 2.0 and
whether they really need to be nodes at all; see
http://www.w3.org/TR/query-datamodel/#NamespaceNode)
>> 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.
>
> I think we do for a few reasons. What is considered the base URI of
> those annotation nodes?
That is tricky; I suppose that the only real options are
1. that it's the same as the base URI of the source document
2. that it doesn't have one
3. that one is made up, based on the base URI of the source document
I think that 2 is probably the most accurate -- the documents to which
the "annotation nodes" (element nodes accessed through the
annotation:: axis) belong are documents that don't exist as physical
documents, therefore they don't have a base URI.
> What happens if one navigates the parent or ancestor axis on one of
> them, or uses an absolute path with an annotation node as context?
I think that it depends on the kind of annotation. For example, say
that someone defined a set of annotations for the Infoset that
described the Infoset as XML. Alongside the normal document:
<foo><bar /></foo>
there would be an Infoset document:
<info:element namespaceName="" localName="foo" prefix=""
baseURI="...">
...
<info:children>
<info:element namespaceName="" localName="bar" prefix=""
baseURI="...">
...
</info:element>
</info:children>
</info:element>
If you did:
bar/annotation::info:element
say, then you'd get the <info:element> for the 'bar' element from the
Infoset document as above. The parent of that <info:element> element
is the <info:children> element of the <info:element> element that
represents the foo element.
In other words, the Infoset XML document exists as a separate XML
document, in parallel with the actual source XML document; once you
get into that document, then the paths that you use are those in that
document.
What I had in mind was that the "annotation" of an XML document was
really the association of nodes in the source document with elements
in these other, virtual documents. It would be up to the designers of
a particular module (e.g. an Infoset module or a PSVI module) to
decide what the structures of these other virtual documents were; all
that XPath-NG would really have to do is put in place an 'annotations'
property in the data model and have, in the core, an axis (or function
even, but I prefer axis) that returns the annotation elements
associated with the context node.
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
