Afternoon all, So one of the things we need[ed] to resolve was how to sensibly handle extensibility and the most sensible approach we've been able to come up with so far is one based on domain names. This leaves someone else to take care of splitting up the global namespace so we don't have to run our own registry, or worse, just hope for the best). For XML this typically means using URI-based schemes like http://purl.org/occi/thing#thong, and while this works for machines it's inconvenient for us humans. They also carry a lot of fluff in terms of the URI scheme (http) and delimiters ([:/#.]). The current approach from the spec is "*Attributes defined by this standard reside under the occi namespace (e.g. "occi.abc") but anyone can define a new attribute by allocating a unique namespace based on their reversed Internet domain (e.g. “com.cisco.cdp”).*" but we could potentially drop the "occi" namespace (and be careful to avoid stepping on current and future TLDs), or better yet, set a good example by choosing a sensible domain name (ideally occi.org but that's not available). The current domain (occi-wg.org) is not only fugly but refers to this working group rather than the spec itself. The reason I'm raising this (more as an FYI than anything else) is because Tim Bray's just done a nice post "On Namespaces<http://www.tbray.org/ongoing/When/201x/2010/01/17/Extensible-JSON>" in which he suggests to "Do It Like Java" - and that's exactly what we've done, and it's what the Sun Cloud API has done too. Sam PS If anyone does have a suggestion for a sensible domain - or even a more sensible name for the standard (which is a protocol moreso than an interface at this time anyway) then we're all ears.