[
Lists Home |
Date Index |
Thread Index
]
"Rick Jelliffe" <ricko@allette.com.au> wrote:
| (Indeed, there is a further problem with thinking of IDs in terms of
| database keys: that is in thinking that an XML document is indeed a
| database, in the sense of being a collection of facts.)
I've seen even worse examples of db-think. For instance, wanting to use a
database key as the *value* of an ID in a document.
http://lists.w3.org/Archives/Public/www-html/2000Feb/0046.html
| IDs are one end of the non-tree structure in an XML document, a target
| for links. So perhaps they don't have enough scope: perhaps documents
| should be given "keyscopes" which allows elements with IDs from one
| document to be pasted into another.
Isn't this just the "how do we do inline SUBDOCs" problem? IOW, we would
like to treat parts of the instance tree as independent documents, given
that documents inherently scope the categories used in them. (Actually, I
still don't understand this holy grail of blind cut-n-paste - seamless
syntactic integration without rewriting of any kind.)
| Here is a mechanism, rather like the dreaded namespaces [...] to
| demonstrate what I mean: [example omitted] In other words, instead of
| (or as well as) the typing focus of what elements can be pointed by
| another element (i.e. the kinds of concerns that keys raise) perhaps we
| need to consider the modularity/document composition concern of how to
| allow cut and paste between documents without having to reallocate IDs.
| So that IDs are universally unique.
But they already are, insofar as the documents scoping them are unique.
What could be needed besides a means to say "a SUBDOC is rooted here"?
(And possibly, a means to say "outer scope resumes at this root"?)
| What might a suitable keyscope URI be? Well, initially it can be
| the original document that the data was cut and pasted from.
| This brings us to a kind of transclusion: we keep track of the
| source of the fragment.
|
| <x>
| <y keyscope=" http://www.eg.com/somedocument.xml ">
| <z id="a1" />
| <zref idref="a1"/>
| </y>
| <y>
| <z id="a1" />
| <zref idref="a1"/>
| <zref idref="aa:a1" keyscope:aa=" http://www.eg.com/somedocument.xml "/>
| </y>
| </x>
But we don't want to - make that, shouldn't - use IDREFs that way.
| where some smart software could figure out that there was some equivalence between
| <zref idref="aa:a1" keyscope:aa=" http://www.eg.com/somedocument.xml "/>
| and
| <zref xlink:href="http://www.eg.com/somedocument.xml#a1 "/>
Is this a reference to the fragment in the original document, or the copy
cut-n-pasted into this document? Would an xlink processor have to figure
out that accessing an external document can be obviated because a local
copy exists? And can we be sure that the local copy is a faithful one?
I'd say the only consistent usage would be the moral equivalent of an
IDREF scoped to the (original) document with the relevant ID.
<zref uref="a1" idsrc="http://www.eg.com/somedocument.xml";
extloc="uref idsrc" >
i.e. the *name* 'extloc' is used to identify the value of the 'uref'
attribute as a reference to an ID in the document located by the 'idsrc'
attribute. We would know this is an external reference as long as idsrc
were required to be an URI. If, instead, we wanted to refer to the local
cut-an-pasted copy (which, dare I say ontologically, has a distinct
existence if not identity), we could do something like this
<x>
<y id="a2" keyscope=" http://www.eg.com/somedocument.xml ">
<z id="a1" />
<zref idref="a1"/>
</y>
<y>
<z id="a1" />
<zref idref="a1"/>
<zref uref="a1" idsrc="a2" intloc="uref idsrc"/>
</y>
</x>
Where, however, idsrc is now an IDREF rather than a URI (thus, 'intloc'
instead of 'extloc'. There are ways to combine all this, too, but I dare
not mention the H-word.)
|
