Sorry, forgot to CC the list. ---------- Forwarded message ---------- From: <shlomo.swidler@gmail.com> Date: Wed, Jun 24, 2009 at 11:43 PM Subject: Re: [occi-wg] Ambiguity regarding Collections To: Sam Johnston <samj@samj.net>
Great - we discussed how the specification would be documented on today's call and there was some concern that it wouldn't be long/formal enough if we continue on as I've started but I'd prefer to produce something that is as concise as possible (ideally no more than a few pages).
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. 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?
- 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. .. Shlomo