Hi, once again I would like to reiterate the JSON rendering. First a short overview what Alexander and I think are the main points we should address: - remove all HTTP Rendering specific parts from the JSON rendering - make the JSON rendering slim and remove everything which is not a representation of the OCCI model - consider using RFC 5988 "Web Linking" for collection information (e.g. index, next, previous,…) Examples: http://pastebin.com/ZK9Uf0K1 (Entities) http://pastebin.com/cKGw9pz6 (Categories) To keep the mail short, a detailed discussion can be found in the attached text document. Cheers, Florian
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
------------------------------------------------------------------------------- GWDG - Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen Am Fassberg 11, 37077 Göttingen Fon: 0551 39-20364 Fax: 0551 201-2150 E-Mail: florian.feldhaus@gwdg.de WWW: www.gwdg.de ----------------------------------------------------------------------------------- Geschäftsführer: Prof. Dr. Ramin Yahyapour Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger Sitz der Gesellschaft: Göttingen Registergericht: Göttingen Handelsregister-Nr. B 598 -----------------------------------------------------------------------------------
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg