[occi-wg] Ambiguity regarding Collections

[Sam Johnston]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090624/ca9efe9d/attachment.html