[occi-wg] Core errata

Feldhaus, Florian florian.feldhaus at gwdg.de
Tue Sep 25 05:45:58 EDT 2012


Am 25.09.2012 um 11:40 schrieb Ralf Nyren:

> On Tue, 25 Sep 2012 09:05:11 +0000, "Feldhaus, Florian"
> 
> <florian.feldhaus at gwdg.de> wrote:
> 
>>> 
>>> For the sake of backward compatibility I agree we probably cannotrequire
>>> Entity.ID to be a UUID. A "SHOULD" is an acceptable compromise IMO.
>> 
>> ok, could you update the OCCI draft then?
> 
> Sure. I will add that together with the appendix summarizing the errata
> changes.
> 
>>> Just to clarify, do you think that OCCI Core should recommend a specific
>>> format of the Entity IDs as well?
>>> 
>>> I mean, even if Entity.ID is a UUID there are multiple ways to represent
>>> a UUID. E.g. canonical form, binary format, URN, etc.
>>> 
>>> Having a specific ID format specified directly in OCCI Core would
>>> definitely help with consistency across renderings. However from a
>>> technical perspective I think the particular UUID format to use should be
>>> up to the rendering.
>> 
>> Currently the ID format is specified to be the URI format. I wouldn't
>> change that for this revision.   
> 
> So, it would be up to the implementation to decide whether to render Entity.ID
> as e.g. a URN or an URL with a UUID at the end? (URI = URL | URN)
> 
> Strictly speaking if Entity.ID is a URI, the following would not be valid right?
> 
> { 
> 
>  ...
> 
>  id: "1b1fcb26-b675-4827-a479-ad77382f51a6"
> 
> }
> 
> (taken from the JSON data format examples)
> 
> It would have to be "urn:uuid:1b1fcb26-b675-4827-a479-ad77382f51a6"
> instead if I understood the RFC.
> 
> regards, Ralf

You are right, my fault. I will update the examples in the JSON spec.

Cheers,
Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/occi-wg/attachments/20120925/9f65d5e6/attachment.bin>


More information about the occi-wg mailing list