On Tue, May 12, 2009 at 5:53 PM, Tim Bray <Tim.Bray@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