[occi-wg] Namespaces & Extensibility

[Alexander Papaspyrou]

Good idea, Chris. I totally overlooked that, although we used it many  
times already... :-/

Best, Alexander

Am 19.01.2010 um 00:06 schrieb Christopher Smith <csmith at platform.com>:

> There was an OGF community practice document published on namespaces  
> that is probably relevant here. I would suggest following it’s conve 
> ntion.
>
> “Standardised Namespaces for XML infosets in OGF “ (http://www.ogf.org/documents/GFD.84 
> .pdf).
>
> -- Chris
>
>
> On 18/1/10 13:54 , "Alexander Papaspyrou" <alexander.papaspyrou at tu-dortmund.de 
> > wrote:
>
> Sam,
>
> w.r.t Tim Bray's comment "Do it like Java", occi.<whatever> seems  
> perfectly sensible to me.
>
> Another option would be to take org.ogf.occi.<whatever>, since OGF  
> is the standardizing OCCI anyway and the ogf.org <http://ogf.org>   
> domain---including subdomains---is under control of the OGF  
> corporation.
>
> -Alexander
>
> Am 18.01.2010 um 21:55 schrieb Sam Johnston <samj at samj.net>:
>
> 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 
>  <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 t 
> o avoid stepping on current and future TLDs), or better yet, set a g 
> ood example by choosing a sensible domain name (ideally occi.org <http://occi.org 
> >  <http://occi.org>  but that's not available). The current domain (occi-wg.org 
>  <http://occi-wg.org>  <http://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.
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20100119/15b06359/attachment.html