Re: [office-metadata] Differences of our binding/identificationspropsals, possible settlement

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

Bruce D'Arcus wrote:
>
> On Mar 20, 2007, at 11:05 AM, Svante Schubert wrote:
>
>> It seems the differences between our proposals is are not that large.
>
> Yeah, and I just had an epiphany that this might be easier than we 
> think ...
>
>> The reason is we won't define in our spec, how to refer to a remote 
>> document, anyway. It is up to the user / plugin, which IRI is being 
>> used.
>> The remote document can be described by a created ID as you suggested
>>    
>> tag:odf:550e8400-e29b-41d4-a716-446655440000:6B29FC40-CA47-1067-B31D-00DD010662DA 
>>
>> or a URL pointing to the document or any other IRI.
>> I assume that the ID is only being used, when the document is final, 
>> otherwise the relation would broken too easily.
>> It seems reasonable to suggest a common naming schema in an 
>> informative section.
>
> Actually, the idea I had that simplifies this is the following:
>
> The version-id would *not* be used for subject URIs within graphs. 
> They would only -- and optionally -- be used for named graphs where 
> come application or plug-in needed to version-control its metadata.
>
> That gives us a stable and unique (apart from the cp scenario, which 
> we cannot control) ID for the document, and yet versioning can still 
> work.
I am fine with this. But is it really necessary to make this ID 
mandatory, i.e. require it to be used instead of the placeholder 'odf:/'

Just to make sure that we are all aware of the two kinds of copy 
problem. One is the OS copy command. The other where people are taking 
existing documents as templates, saving them under different names. 
Meeting-minutes or presentations are often created by myself this way. 
Probably somewhere else even business offers by secretaries.
Using the UUID approach the edited document would be the same as the one 
used as template.
>
>> The following further differences we had in our proposals:
>>
>> - The type of the IDs, you recommend twice a UUID, I would rather use 
>> an IRI and a integer, is it fine to agree on two strings and suggest 
>> UUID informative?
>>   By this the URI as document ID with version as integer suffix would 
>> be still possible.
>>
>> - If I understand it right, you want to refer to internal IDs as well by
>> tag:odf:550e8400-e29b-41d4-a716-446655440000:6B29FC40-CA47-1067-B31D-00DD010662DA/content.xml#foo 
>>
>> I suggest to facilitate this by exchanging the prefix for the 
>> internal resources of a package by odf:.
>> Imagine someone have to exchange all IDs, when the document is being 
>> changed and saved. The ODF application does not want to mess with RDF 
>> application data.
>
> Right, but if we don't worry about the version-id as above, this 
> becomes a non-problem.
Aside of size and readability - a human reader might miss during a 
compare the difference of a single digit UUID-, why not keep it short 
and verbose using
    odf::/content.xml#foo

I like the flexibility to match the URI of odf::/content.xml#foo 
describing an ODF resource either by
    tag:odf:550e8400-e29b-41d4-a716-446655440000:content.xml#foo
according to UUID of the meta manifest attribute.

Or if the user is aware that the location won't change by
    
jar:http://www.oasis-open.org/committees/download.php/22812/07-03-07-ODF-MetaData.odt!/content.xml#foo

Therefore, the document itself can be identified by location or ID. Can 
not the ODF elements as <text:p xml:id="foo" being described neutral to 
the identification approach using odf:/styles.xml#foo?

What other pro/con do you see?
>
>> If someone parses the RDF data for external use, the prefix might be 
>> exchanged by some IDs (e.g. as you suggested) or a path/local URL. 
>> Leave it to the them.
>> This would give us flexibility. If someone likes to argue that is not 
>> standard procedure, we can say it will become standard, similar as 
>> our ODF RDFa elements.
>>
>> Does this help?
>> Svante
>>
>>
>>
>>
>