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
