Binding proposal(s) status for the call

[Svante Schubert <Svante.Schubert@Sun.COM>]

Hi,

I would like to summarize the current point of discussion regarding 
identifying ODF elements and their binding with in-package RDF/XML and 
binding from outside the document.

We are all aware that by the common habit in using office documents 
(e.g. copying, using existing documents as templates, duplication by 
mail attachment) global unique identification is rather an ideal than 
reality. Nevertheless the ID for documents could be held unique in 
controlled work-flows and external RDF statements might refer to this 
document by this ID.

document-id
=========
We therefore agreed on the existence of an ID, but have different 
proposals about the ID:

If someone external would like to refer to the document, he might use a 
string similar to this
    "tag:odf:550e8400-e29b-41d4-a716-446655440000"
It is unclear, if this ID is the value of an attribute of the meta 
manifest or is it being constructed from various attributes similar to a 
suggested
    " 
tag:odf:550e8400-e29b-41d4-a716-446655440000:6B29FC40-CA47-1067-B31D-00DD010662DA"
which only refer to a certain version of the document.

I prefer to use the string as value of an attribute, by this we would 
have a simple well defined ID.
On the other hand, if we construct it, we would have more flexibility in 
variations as above.
But as all variations of docIDs take the first docID as prefix, I would 
suggest the docid to be an IRI, described in the given formation in an 
informative section.

revision-id
=======
 From my current point of view, I see only a comparable small subset of 
use cases for this attribute.
As the relation is broken after change of the version ID and this 
already is done after any change of the whole document, this appears to 
me a rather seldom use case. I suggest therefore to drop this feature at 
least for this version of proposal.


in-package binding
=============
We have currently two proposals for the binding, where in the package 
(e.g. from a RDF/XML file) is being referenced to an ODF element with a 
xml:id:
tag:odf:550e8400-e29b-41d4-a716-446655440000:/content.xml#myID
or
odf:/content.xml#myID

The latter is an odf: URL, which refers only to in-package content.
I favor it for several reasons:

1) If someone would like to rename the document (an expected Office 
feature), all document internal bindings stay valid. The ODF application 
changing the docID will NOT interfere with RDF/XML data!
2) The docID is likely to be only unique in controlled work-flows. Using 
it always, gives a wrong implication.
3) Size & readability advantages
4) Only before extracting data relative to the document, it will be made 
global, the one extracting the information has still the choice using 
the docID or the location URL, but might as well add owl:sameAs to give 
a relation of location and docID. By this it would have at least a 
chance to realize same docIDs for several files.

We might want to discuss this in our call today (remember European: it's 
still an hour earlier this week, e.g. 4 o'clock for Hamburg).

Bests,
Svante