Binding proposal

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

Hello group!

After several discussions here at Sun and a week-end of reconsideration, 
one thing seems clear now:
It makes little sense to trust on an identification mechanism, that can 
be so easily annulled as by a file copy.
We doubt that any company would rely their data on such fragile 
mechanism, unless a special work-flow is being used for documents in the 
company.

Taking into account our lack of time and the seizable unclarity on this 
list, I suggest to drop sophisticated identification mechanisms, 
especially as no other document standard has entered before something 
similar to it's format.

What can we simplify to come to a solution?

Do we need a world-wide scope of identification?
For example, when a content mgmt system (cms) holds data, the data will 
be kept unique for it's system, in a second (cms) the data might be 
duplicated, as the scope is only for one system.
Metadata is being created for one document, the scope of reliability is 
the document itself.
As any ID mechanism between documents can be overthrown by file copy, 
the only trustworthy identification of the document can be made from 
outside the document.
For instance, the access of a document makes a document unique for the 
accessors or documents received by mail might be identified by sender 
and time.

Nevertheless to aid above scenarios of controlled work-flows, it still 
seems useful to specify in the meta manifest two attributes for a 
document ID and revision.
I would not request UUID as uniqueness is known to be fragile. I would 
rather suggest any IRI for the ID as they are easier to create from the 
scratch and can be used to reference to further information and an 
integer for the reversion. Aside of this even the introduction of a base 
URL makes sense.

Regarding the binding:
If we agree on the simplification, that the scope of identification is 
the document itself, we still have a different option than to use 
relative URLs:
As we have already discussed to create our own URL from various IDs and 
we still want to avoid problems with relative URLs, I suggest to relate 
to ODF resources by a ODF URL pointing to a resource:
"odf:/content.xml#myID"
As odf:/ references to the root of the package, followed by the 
reference to the resource, the uniqueness of this ID is guaranteed for 
the package.

Regards,
Svante