Re: [office-metadata] Binding proposal

[Bruce D'Arcus <bruce.darcus@OpenDocument.us>]

On Mar 20, 2007, at 6:19 AM, Svante Schubert wrote:

>> But you're not solving the problem: you're avoiding it. Using 
>> "odf:.." as you propose is functionally the same as using 
>> "file:///..."
> The odf: would only refer into the same ODF package, it is not 
> relative to the document location, by this different to file://

But what's the identity of "the package"? That's what we need to 
define, and it needs to be stable and globally unique.

> Bruce, maybe we should not try to solve the problem of document 
> identification in the document as there are risks we can not control: 
> Some XSLT / webapplication / ODF application might not exchange the 
> revision ID, but the document.
> Why should we burden the identification effort to an ODF application, 
> when in the end a guaranteed identification would be made from the 
> outside?

I disagree with "made from the outside" part. I'd say we can defer to 
the user perhaps (it's up to the user to change the URI for the 
document if they do a CP), but the identity of a document is 
fundamental thing.

> What do we really gain? The UUID tells nothing about the document type 
> nor the location. Whenever we analyze the metadata of a document, I am 
> sure we would rather have a link to the document or could use some 
> more verbose identification mechanism as sender/time/etc.

Good question: what do we lose if we don't get this right? We lose the 
ability to reliably define an ODF document or document fragment as an 
object of a triple. This means we cannot do the following with any 
reliability:

	- defining relations among documents (I say this document is a part of 
that document, and so forth)
	- annotating documents externally (Rob's "extrinsic metadata" use case)

... no doubt the list could be much longer.

> Is the introduced complexity really worth it's gain?

I don't think we should cripple the identification scheme just to 
account for the cp scenario. I think at minimum the document needs a 
URI that can serve as the base, and that we recommend urn:uuids as a 
very good fallback (if user doesn't define there own URI, use a 
urn:uuid).

I don't like the file:/// and odf: options for the reasons I've 
outlined before (they are either not stable, or not unique).

Bruce