Ambiguity regarding Collections

[I've been a lurker here since the very beginning of this list. I'm an end-user, interested in using OCCI to allow me to minimize the vendor lock-in of my cloud deployments. I have experience in writing and implementing specs of the JSR kind.] There seems to me to be some potential ambiguity in the "spec" regarding collections. I'm referring to the HTML attached [1] to the most recent Conference Call agenda (which I did not attend, so forgive me if this was discussed). The document says: Operations that return multiple resources (e.g. categories, searches) are rendered as an Atom feed with an Atom entry per resource. Does this mean that a conforming implementation can, if there is only a single resource to return, choose to return it as a collection of length 1 OR as a "flat" description without Atom wrapping? Or, does it mean that "operations that, by their nature, can potentially return multiple resources (such as search) will return these results enumerated via an Atom feed REGARDLESS of how many results there are"? .. Shlomo [1] http://www.ogf.org/pipermail/occi-wg/attachments/20090624/01218d83/attachmen...

On Wed, Jun 24, 2009 at 9:55 PM, <shlomo.swidler@gmail.com> wrote:
[I've been a lurker here since the very beginning of this list. I'm an end-user, interested in using OCCI to allow me to minimize the vendor lock-in of my cloud deployments. I have experience in writing and implementing specs of the JSR kind.]
There seems to me to be some potential ambiguity in the "spec" regarding collections. I'm referring to the HTML attached [1] to the most recent Conference Call agenda (which I did not attend, so forgive me if this was discussed).
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).
The document says: Operations that return multiple resources (e.g. categories, searches) are rendered as an Atom feed with an Atom entry per resource.
Does this mean that a conforming implementation can, if there is only a single resource to return, choose to return it as a collection of length 1 OR as a "flat" description without Atom wrapping? Or, does it mean that "operations that, by their nature, can potentially return multiple resources (such as search) will return these results enumerated via an Atom feed REGARDLESS of how many results there are"?
My initial plan was to use Atom regardless of the cardinality (following Google's example with GData which is essentially just AtomPub) but there was stiff opposition to XML. The simplest way to retain the flexibility while dropping the absolute requirement for XML support in the clients was to shift metadata to the HTTP headers for individual resources. That is to say: - 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. Cheers, Sam
participants (2)
-
Sam Johnston
-
shlomo.swidler@gmail.com