[occi-wg] OCCI JSON data format

[Feldhaus, Florian]

From the Feedback I received regarding the OCCI JSON data format, I updated the document with the following changes

* changed the name of OCCI Action Categories to OCCI Action reflecting the changes in OCCI Core and in line with the way it is handled in the text rendering
* changed name of OCCI Action to OCCI Action Instance. The Action instance format is now closer to the text rendering of action instantiations
* removed restrictions on ID format, as the format is defined in OCCI Core
* OCCI Link source and target are now URIs
* If only one OCCI Resource is rendered alongside one or more OCCI Links, the OCCI Resource is the source of these OCCI Links if the source entry is omitted. This is now in line with the inline rendering of links in the text rendering
* updated examples
* some formatting changes

From my point of view, the document is now quite mature and I would like to ask everyone to go through the document in detail and report back all outstanding issues, including spelling and grammar mistakes!

Cheers,
Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: json_rendering.pdf
Type: application/pdf
Size: 120832 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/occi-wg/attachments/20120924/10a87e5a/attachment-0001.pdf>
-------------- next part --------------


Am 27.08.2012 um 15:14 schrieb Feldhaus, Florian:

> After the discussion in the OCCI ConfCall Ralf and I went through the JSON document and identified open issues and how we would solve them. The result is attached as pdf and committed to the new JSON branch in the OCCI WG Git.
> 
> Following is a short explanation of the design goals:
> * the overall design goal was to create a data format which is independent from the transport protocol
> * also important was a compact representation of all OCCI Entities as they may be exchanged very often
> * OCCI Categories could be verbose to describe the Model in detail
> * information should be easily accessible
> 
> Some explanations on specific sections:
> 4.1 - for attributes the dot notation should be used and each namespace should be rendered as a separate object. This follows best practice in JavaScript to handle nested attributes and should help adoption.
> 4.2 - type identifiers as used for 'kind', 'mixins' and 'action_categories' are pointers to other objects within the OCCI Core scope and thus are rendered in the top level object.
> 4.2 - id is rendered in the top level object. The reason is, that id is a pointer to the object itself, thus it is not an attribute, but a OCCI Core property of the object itself comparable to 'self' in many programming languages. Besides it is difficult to specify rules on how id must be rendered if it is not in the top level object.
> 4.2 - links are represented by the URN of their id following RFC 4122. This is a more compact representation of the link as we had it before. Also it resembles the behavior of id. Thus it is rendered in the top level object
> 4.3 - source and target are also pointers to objects within the OCCI Core object scope. Thus they are rendered in the top level object. Similar to id it is difficult to specify rules on how source and target must be rendered if they are not within the top level object.
> 4.3 - the type identifier in 'rel' is a pointer to a OCCI Category and thus rendered in the top level object
> 4.4 - instantiated actions need to be represented in a format similar to that of OCCI Entities. Actions don't have an 'id' as they are only used once and are not persistent
> 4.5 - term, scheme, attributes, actions and related are OCCI Core properties of the 'kind' object and thus rendered in the top level scope
> 4.5 - location is transport protocol specific, but must be an URI. Each transport protocol must specify guidelines for location
> 4.7 - the action category format is used to define actions similar to kinds describing OCCI entities
> 4.8 - the attribute description format has been simplified. The general description of attributes went to 4.1. The attribute properties have been reduced to mutable, required, type, default and description. As Pattern complicated matters a lot it was removed.
> 
> Cheers,
> Florian
> <json_rendering.pdf>_______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/occi-wg

-------------- 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/20120924/10a87e5a/attachment-0001.bin>