This is yet another reason why it's important to have multiple,
independent implementations: spec ambiguity can be discovered by
comparing the differences between implementations.

There's a few different options for this but outside of any reference implementations we develop alongside the spec (e.g. the one I whipped up on Google App Engine earlier) I think it's something we can focus on once we have a draft out the door (which I hope will happen very, very soon).

Have you considered having an official "OCCI Compatibility Test",
which could be an impartial arbiter of whether or not a given
implementation is spec compliant?

Sure, that's a good idea but who's to say our implementation will be any better than any other? Bakeoffs tend to work well too.

> - If you retrieve a representation of a single resource you will get just
> the representation itself (with the metadata out of harm's way in the
> headers)
> - If you instead request something that *could* return multiple resources
> (e.g. a category, search, etc.) then you will receive a feed with zero or
> more entries.

This seems OK to me, as long as the disposition of each method
(whether it only ever returns a single resource, such as GET
/compute/uuid1, or whether it can return multiple resources, such as a
search) is clearly indicated in the spec.

Yup, agreed (and at least for now this is certainly the case). I forgot to mention that one of the key reasons for this approach is to lower the barriers to entry (it becomes trivial to "kick the tyres" - even with nothing more than a browser) and to allow for very simple clients like scripts and cron jobs to do routine tasks (e.g. integration and automation).

Sam