[occi-wg] Simple JSON rendering for OCCI

[Sam Johnston]

On Tue, May 12, 2009 at 5:53 PM, Tim Bray <Tim.Bray at sun.com> wrote:

> On May 12, 2009, at 4:20 AM, Sam Johnston wrote:
>
>  These are both valid alternatives but given our ultimate aim is to reduce
>> costs it makes [a lot] more sense to have a primary format which supports
>> mechanical transforms than to externalise the development to implementors
>> (and then expect the results to be interoperable).
>>
>
> You have argued on many occasions that mechanical transformation of the
> OCCI protocol data format is a key requirement.  I've never understood why,
> and I've never engaged in a protocol design where this was an issue.  Could
> you expand on why this matters?  -Tim


True, but I've also cited on many occasions use cases that rely on specific
formats. Here's a dozen that come to mind and would otherwise have to be
manually coded by each implementor:

   - Sysadmins conducting routine tasks with shell scripts (TXT)
   - Task scheduling with cron (TXT)
   - Automatic/autonomic task mechanisation, e.g. failover, recovery (TXT)
   - Users wanting to learn the API/kick the tyres by hand (TXT)
   - Exporting of [collections of] resources in arbitrary formats (OVF, VMX,
   etc.)
   - Documentation generation (ODF)
   - Report generation (PDF)
   - Diagramming (SVG)
   - Accounting (CSV)
   - Mapping to other protocols/implementations (EC2)
   - End user web interface (HTML)
   - End user RIA (XUL)
   - etc.

As for standards, one could point at XML and the subsequent need to create
XSLT ;)

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090512/5a1deaa8/attachment.html