Quoting [Sam Johnston] (May 15 2009):
Yes, we would need both - registries primarily for change management of attributes, states, etc. and full-blown extensions for more advanced topics like adding new resource types/styles (e.g. load balancers). I'd suggest breaking up the workload as follows: * Adopt AtomPub (+search, caching, etc.) as OCCI Core - lots of hard work already done (the alternative will almost certainly involve another OGF cycle, pushing the final delivery out to OGF 28 which is yet to be scheduled in 2010) * Specify compute, storage and network resources as separate extensions (probably in that order) * Specify state control as an extension <- at this point we have our implementable draft * Specify billing, performance monitoring, etc. as extensions * Flesh out over time based on demand for features
Looks good to me. Although Atom, which you favour, is still not decided upon ;-) Anyway, procedure and timeline look sensible, IMHO. FWIW, OGF28 should be around March 2010.
One huge advantage of this approach is that we don't have to wait until the end before we start implementations - people can start right now (as I have).
PS.: I am not sure if OGF would go into the space of maintaining registries, or such. OGF's business is to produce specification documents, and to host the infrastructure for doing so. But I am sure that, if a registry is the way to go, we'll find a host for that...
One non-technical point to consider when it comes to things like registries is that using neutral ground like IANA make the standard far more likely to be adopted by other SSOs.
Yes, good point. Andre.
Sam
-- Nothing is ever easy.