OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-metadata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office-metadata] Binding proposal



On Mar 19, 2007, at 6:18 PM, Svante Schubert wrote:

> Bruce D'Arcus wrote:
>>> I would not request UUID as uniqueness is known to be fragile.
>> Do you have a source for this claim? AFAIK, the UUID scheme is widely 
>> implemented in software, and is quite reliable. MS uses it, as but 
>> one example.
> UUID in the context of a document, to express the uniqueness off a 
> document is fragile, when the document can simply be copied and the 
> UUID is no longer unique.
> UUID in the context of software interface is a nice thing. There is no 
> interface copy command in software environments.

But you're not solving the problem: you're avoiding it. Using "odf:.." 
as you propose is functionally the same as using "file:///..."

>>> 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.
>>
>> This is an interesting design question. What happens if an 
>> organization has a URI scheme it wants to use to identify documents?
>>
>> I always had this in mind, and to default to a URN UUID. But I'm not 
>> sure how that squares with the versioning problem.
> This was my scenario of a workflow. If a group of companies is 
> exchanging ODF documents and using custom URI schema it is fine as it 
> is a closed environment with defined processes.

But in Elias' earlier post on this, I think he left room for just that. 
The UUIDs for document and version are there so that these URIs *may* 
be constructed in the absence of some other chosen URI.

At least, this is how I understood what he was saying.

Bruce



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]