Detailed discussion of the examples:
- as the JSON rendering is already used for huge numbers of OCCI requests, it should be as slim as possible
- the proposed collection format mixes HTTP rendering information with the JSON representation. A better way would be to hold the collection information either in the headers (using e.g. RFC 5988) or in the query parameters of the URI
- resources and links should be represented differently. The entry "links" is unique for resources and the entries "target" and "source" are unique for links. In OCCI Core the attribute names should be changed from occi.core.source and occi.core.target to just source and target, as both are representing connections to other resources from within the OCCI model (similar to links in resources, or kind in entity).
- for the representation of OCCI objects we see 3 different possibilities
-- render all OCCI classes in one content-type (e.g. application/occi+json) using a hash with entries for kind, mixin, action, resource and link
-- render all category related classes in a content-type (e.g. application/occi-category+json) containing a hash with entries for kind, mixin, action and all entity related classes in a content-type (e.g. application/occi-entity+json) containing a hash with entries for resource and link
- multiple instances should be rendered in an array. What about single instances, should the array be omitted?
-- render all classes with separate content-types (e.g. application/occi-kind+json, .../occi-mixin+json, .../occi-action+json, .../occi-resource+json, .../occi-link+json) without a top-level hash
- attributes should not be rendered in the top level (as previously proposed by me and Jamie), but in a hash named attributes. This allows a better handling in the clients. Having attributes in the top-level would also allow collisions if e.g. an attribute name starts with a one of the reserved keywords like kind, mixins, action, links, source, target.
- We have to find a solution for singular and plural names for attributes.��
-- Should kind always be singular?��
-- Should mixins always be plural?��
-- Should the collections always be plural (e.g. kinds, mixins, actions, resources, links)?
- The shortest representation for kinds, mixins, links, source, target are the type identifiers. Additional information may be helpful for the client. We see 2 possibilities
-- create a hash for every entry containing at least the type identifier and optional more information like kind, mixins, related, ...
-- render only the type identifiers. Very compact and no additional hash needed