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] Revision and stable ids


Svante.Schubert@Sun.COM wrote on 03/15/2007 03:54:28 PM:

> Bruce D'Arcus wrote:
> >
> > On Mar 15, 2007, at 2:01 PM, Svante Schubert wrote:
> >
> > ...
> >>> A revision id (another UUID) generated when the document opens and
> >>> available for minting new URIs, but only committed upon saving the
> >>> document.
> >>>
> >> Another UUID, not an Integer?
> >
> > It's probably more reliable for it to be another UUID, precisely to
> > account for the extreme case of your cp example. The base UUID would
> > be the same between the instances, but the version numbers would
> > always vary between them. Therefore, the constructed URIs would also
> > vary.
> The UUID would give us no advantage, the copy won't know being a copy.
> Furthermore, if the revision is not incremented, but being generated,
> numbers are not ordered and can not put into a chronological sequence.
> In this case we might use as well hash-values as used in peer-to-peer
> file exchange.
>
> Svante.

Why does the copy need to know it's a copy? Also, aren't we slowly stepping
in out of scope territory with the cp scenario?

A list of revision ids can be maintained. However, the problem is that if
we use integers then both files can have the same UUID/revisionInteger
URIs. Then what were we trying to resolve? Sometimes I forget.

-Elias



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