So, what this discussion basically boils down to is, that this group should do two steps: A) define the nouns and verbs for the API, and nail down semantics for them B) do different bindings for the result of (A) Looks sensible (to me), and there seem to be enough people around who can check the process in (A) for implementability in the various options of (B). Is that what it is going to be? Andre Quoting [Sam Johnston] (Apr 16 2009):
On Thu, Apr 16, 2009 at 7:09 PM, <[1]eprparadocs@gmail.com> wrote:
I'd +1 moving back to simplified XML from INI.
We didn't move as such - a plain text version of the API for dumb clients (like shell scripts and humans armed with curl/wget) makes sense, as does a web-friendly JSON/YAML option. XML can be reserved for the hardcore stuff but if you've got to parse XML anyway you may as well parse Atom - trust me, a lot of the stuff you end up trying to deal with (such as categories, links, etc.) are already done for you and there's a heap of code and developers who already grok it (e.g. Google GData APIs). Basically I'm trying to extract the best points of all of the APIs and leave the cruft (such as in-band authentication) behind. Sam
References
1. mailto:eprparadocs@gmail.com
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- Nothing is ever easy.