Re: [office-metadata] Revision and stable ids

[Bruce D'Arcus <bdarcus@gmail.com>]

On Mar 15, 2007, at 4:03 PM, Elias Torres wrote:

> Why does the copy need to know it's a copy?

I don't think it does.

> Also, aren't we slowly steppin in out of scope territory with the  
> cp scenario?

Actaully, I thought *you* brought us back to the cp scenario  
yesterday. I thought this was why you proposed the version ID as UUID  
(earlier I thought you had thought of it as an integer)?

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

I thought you had the clearest view of this all, so now you have me  
worried :-)

My understanding is we've just stumbled into "devil in the details"  
territory, and that the challenge here is to have a mechanism that  
will allow stable URIs to be generated that can account for documents  
which:

a) change state (get edited)
b) move

It seems to me the id + version id approach, where both are UUIDs, is  
probaably the best approach. It's true you can't order by the value,  
but maybe the manifest entry could include a timestamp?

In any case, the more I think about this, the more I think this  
business of versioning -- while important for us to think about -- is  
not really central to what we're doing. My hunch is the two document  
IDs plus named graphs gives enough flexibilty for implementors to  
work out the details as they need to. And I bet that versioning will  
not be close to the most common implementation scenario.

This is difficult and important stuff, and no matter what technology  
approach we would use, we'd stumble on similar conceptual and  
technical difficulties. For example, if we'd used XML and XPath, we'd  
not have been able to solve the versioning issue either (since an  
XPath expression is about location basically). So we might try to  
simplify where we can.

So as a strawman resolution to this issue so that we might move on,  
I'd like to suggest:

1. document gets two required IDs; a document-id and a version-id.  
The first is stable and never changes. The second changes upon saving  
the document.

2. Both document-id and version-id are to be UUIDs.

3. URIs for statements about document content (tables, paragraphs,  
etc.) get constructed from the document and version ids as Elias has  
been suggesting (details TBD)

4. we explain in the proposal that the named graph support can be  
used for x, y, z, including versioning

Another possibility is to throw out xml:id for metadata altogether.  
In that case, we would not be constructing URIs at all. That would  
introduce other problems though (like the versioning stuff).

Bruce