[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