[occi-wg] Namespaces & Extensibility

Sam Johnston samj at samj.net
Mon Jan 18 14:55:16 CST 2010


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


More information about the occi-wg mailing list