[occi-wg] Ambiguity regarding Collections

[shlomo.swidler at gmail.com]

Sorry, forgot to CC the list.


---------- Forwarded message ----------
From:  <shlomo.swidler at gmail.com>
Date: Wed, Jun 24, 2009 at 11:43 PM
Subject: Re: [occi-wg] Ambiguity regarding Collections
To: Sam Johnston <samj at 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