Content Negotiation: Alternative Formats
Ok so let's try to get some clarity around the various alternative formats and use sensible names for them now on - we can do a lot better than "Sam's GData XML" vs "My Simple JSON". Here's a few that come to mind: - *AtomPub* <http://en.wikipedia.org/wiki/Atom_%28standard%29>: Atom meets REST or "*a simple HTTP-based protocol for creating and updating web resources*" - *CSV <http://en.wikipedia.org/wiki/Comma-separated_values>*: Comma Separated Variable ala GoGrid, useful for reporting, asset registries, etc. - *[X]HTML <http://en.wikipedia.org/wiki/HTML>*: Web interface for end users, optionally with semantic markup - *JSON* <http://en.wikipedia.org/wiki/JSON>: JavaScript Object Notation or "*a lightweight computer data interchange format*" - *PDF <http://en.wikipedia.org/wiki/PDF>*: Portable Documentation Format, useful for documentation and reporting - *POX* <http://en.wikipedia.org/wiki/Plain_Old_XML>: Plain Old XML - *TXT*: Plain Text API (e.g. "KEY VALUE", "X|Y|Z", etc.) I'm hoping we agree to one required core format and then leave it up to implementors to decide what they feel like rendering. Sam ---------- Forwarded message ---------- From: Richard Davies <richard.davies@elastichosts.com> Date: Wed, May 13, 2009 at 2:47 PM Subject: [occi-wg] Format: 4 distinct decisions To: occi-wg@ogf.org * Decisions 3 and 4 are independent. Sam's GData XML http://www.ogf.org/pipermail/occi-wg/2009-May/000381.html is 3b with 4a. My Simple JSON http://www.ogf.org/pipermail/occi-wg/2009-May/000523.html is 3a with 4b. But equally it would be possible to specify GData JSON (3b, 4b) or Simple XML (3a, 4a).
Ok so let's try to get some clarity around the various alternative formats and use sensible names for them now on - we can do a lot better than "Sam's GData XML" vs "My Simple JSON".
Yes, I agree we can do better than that!
* AtomPub: Atom meets REST or "a simple HTTP-based protocol for creating and updating web resources"
I do feel that this is the combination of a meta-model (AtomPub, decision 3) and a syntax (XML, decision 4), which are logically independent, as evidenced by the existence of both GData-JSON (same meta-model, different syntax) and POX (same syntax, different meta-model).
* JSON: JavaScript Object Notation or "a lightweight computer data interchange format"
So I would equally recommend that we distinguish GData-JSON from POJSON, where POJSON is a direct rendering of nouns, verbs and attributes, by analogy to POX. Richard.
On Wed, May 13, 2009 at 8:35 PM, Richard Davies <richard@daviesmail.org>wrote:
* AtomPub: Atom meets REST or "a simple HTTP-based protocol for creating and updating web resources"
I do feel that this is the combination of a meta-model (AtomPub, decision 3) and a syntax (XML, decision 4), which are logically independent, as evidenced by the existence of both GData-JSON (same meta-model, different syntax) and POX (same syntax, different meta-model).
Good/interesting observation. Remember there's been talk<http://www.intertwingly.net/blog/2007/01/15/application-atom-json>about application/atom+json and the suggestion<http://intertwingly.net/blog/2007/01/15/application-atom-json#c1169312821>to create an IETF Internet Draft about it.
* JSON: JavaScript Object Notation or "a lightweight computer data interchange format"
So I would equally recommend that we distinguish GData-JSON from POJSON, where POJSON is a direct rendering of nouns, verbs and attributes, by analogy to POX.
I thought this was implicit, but let's call them POJ and POX. While both have useful applications (thinking web development) neither would be a particularly good primary format... before you know it you'll have stuff like ETags, Content Types, Links, Categories and a bunch of other stuff that will make you wish you'd just let someone else do the dirty work. Sam
participants (2)
-
Richard Davies -
Sam Johnston