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



On Mar 15, 2007, at 2:01 PM, Svante Schubert wrote:

...

>> In the manifest we have two ids:
>>
>> A stable (never changing) id, most likely a UUID for purposes of 
>> relating
>> documents to one another.
>>
>> 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.

>> Then all metadata statements must be made on absolute URIs, for 
>> example
>> instead of content.xml#foo:
>>
>> We would use something like this in the meta:about for specific 
>> revision:
>>
>> urn:tag:[stable-document-id],[revision-doc-id]:foo
>>
> Are there two optional 16 byte UUID in this URN?

I think the implications of this discussion is that both UUIDs would be 
required for those applications that edit ODF metadata?

>> or for non-revision specific
>>
>> urn:tag:[stable-document-id]:foo
>>
>>   I would then infer that in-context metadata would only be used for
>> non-revision specific information.
>>
>> <text:p xml:id="foo" meta:about="urn:tag:[stable-document-id]:foo"
>>  meta:property="bar">baz</text:p>
>>
>> or
>>
>> <text:field xml:id="salary"
>> meta:about="urn:tag:[stable-document-id]:salary"
>>  meta:property="ex:salary">1,000,000,000</text:field>
>>
>> Any revision specific can be placed in the RDF/XML files themselves.
>>
> The xml:id foo might be used multiple times in the package, therefore 
> I fear this binding is ambiguous.
> It seems easy to demand the xml:id shall be unique for the whole ODF 
> package, but other applications (e.g. plug-ins) have their XML in the 
> package as well.
> Still the idea is tempting to have an ID to be able to define an 
> element for the whole package.

It might be worth considering whether we're going to too much trouble 
here trying to reuse xml:id. Even if not, could we recommend the value 
of the xml:id (if we do use it) be a UUID also?

>> If we only had one metadata file then on every save we can generate
>> [revision-id]-meta.xml. Then we don't have to worry about building 
>> revision
>> specific IDs.
>>
> This would be a got habit to do so, but the name of the file (the 
> revision) is not part of any RDF graph and worse wouldn't we make 
> ourselves again dependent of the package persistence?

I think Elias would say any graph can have an optional URI. The file 
name is just some convention that has no intrinsic meaning. It's true, 
though, that RDF per se has no formal named graph support, so it would 
be up to implementations to support (associating a URI with an 
in-memory model).

...

Bruce



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