Re: [office-metadata] Binding proposal

[Elias Torres <eliast@us.ibm.com>]

Just to save you time, I gave +1 to everything Bruce said because he
answered everything I was supposed to answer and no, we are not related.

-Elias

"Bruce D'Arcus" <bruce.darcus@OpenDocument.us> wrote on 03/20/2007 08:18:36
AM:

>
> 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.

+1

>
> > 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.

+1

>
> > 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.

+1

>
> > 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).
>

+1