Hi, 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