[occi-wg] OCCI JSON Rendering Draft

[Gary Mazz]

On 5/8/2012 8:17 AM, Feldhaus, Florian wrote:
> Hi all,
>
> I went through the JSON rendering and now there is a first more or less consistent version. I still have to improve some parts and prove read everything, but I wanted to discuss a few points with you beforehand.
>
> Locations
> - do UUIDs have to be globally unique, unique for all resources within a provider, or for all resources of a certain kind?
> ->  I would prefer if we don't restrict this too much, thus it would be sufficient to restrict in OCCI Core, that UUIDs are unique for all resources of a certain kind for one OCCI endpoint. The UUID is created by the backend (underlying service provider) or with information from it. Thus, if the resource is migrated to a different service provider, it gets a different UUID anyway.
CDMI uses the globally unique Object ID of 40 bytes, 32 bytes is opaque 
data.  Its a "real" UUID, not something generated off a path name.  Here 
is the line from the CDMI spec:

    /Every data object has a single, globally-unique object identifier
    (ID) that remains constant for the life of the object. *Each data
    object shall have one or more URI addresses that allow the object to
    be accessed.*
    /


> - I'm not too happy with having the location being part of the kind/mixin rendering, as it is specific to the HTTP representation of the OCCI objects. I thought we might be able to introduce some guideline to derive the location from the term of the kind/mixin and it's related kinds/mixins (e.g. term recursively prepended by term of related kind/mixin). The only problem is, that mixins can have multiple relations. Thus we might have multiple locations for the same mixin. I don't see a problem with it, but it might lead to confusion.
This affects the namespace capabilities.  We should very careful to 
assess before changing core capabilities. Mixins can be configured as a 
single item, a path of mixins or a collection. Defined in the core 
model,  each mixin either standalone or compound must be uniquely 
identified via the 'term'. The location, defines a "single" namespace to 
discover mixin(s).

I believe what you are proposing, that Mixins can have paths based on 
the organization of the mixin relations.  You would need to use the 
unique ids.  Any mixin with different or additional parents must be 
uniquely identified.

Example
Path1: RootMixing/UniqueId1/UniqueId2/UniqueId3
Path2: RootMixing/UniqueId1/UniqueId2/UniqueId3/UniqueId7/
Path3: RootMixing/UniqueId5/UniqueId6/UniqueId3/UniqueId8/
Path4: RootMixing/UniqueId9/UniqueId10/UniqueId3/UniqueId9/  (circular 
reference)

In this example, the only valid definition of mixin "UnqueId3" is Path1 
and Path2.
FF> Link - for Target and Source the URI is sufficient, all further 
information can be retrieved by the client.
GM> I think any unique identifiers use in other queries is important to 
return.

FF> There may also be mechanisms to ask the server to directly supply 
all resources connected via links. But that should be taken care of in 
HTTP rendering then.

FF>- Source is optional when rendered within resource. Then the link 
definition is the same for top level link renderings and link renderings 
within resources.
GM> What do you mean when saying top level link renderings ? Returned to 
the client how ?

FF> Mixins - can mixins be related to kinds? -> I have a resource 
template as example and was wondering, how one would specify 
occi.compute.core for this template. If the mixin is related to compute, 
the attributes are all derived from the compute kind description and can 
be set to new defaults with the mixin.

GM> Mixin is associate with Entity so, Resources and Links.

FF> Action - should action really not be derived from category? -> I 
don't see any reason for the current solution (action containing a 
category). It would be much more consistent, if the Action would also be 
derived from Category.

GM>  Actions may be defined out of OCCI's scope. Deriving Actions from 
Category restricts the capability to include externally defined Actions. 
e.g Actions associated with Mixins.

FF> Attribute description - moved pattern and minimum / maximum out of 
type and into attribute description. This makes it more compatible with 
JSON schema

GM> In the copy I have, "pattern and minimum / maximum"  are already in 
the attribute description

FF> Formatting - Currently the JSON examples are a bit hard to read. 
Maybe we could use the LaTeX package "minted" to do automatic highlighting?

GM> We need lineno for line numbers also.

FF> Cheers, Florian

GM> cheers
>
>
>
> -------------------------------------------------------------------------------
> GWDG - Gesellschaft für wissenschaftliche
> Datenverarbeitung mbH Göttingen
> Am Fassberg 11, 37077 Göttingen
>
> Fon: 0551 39-20364
> Fax: 0551 201-2150
> E-Mail: florian.feldhaus at gwdg.de
> WWW: www.gwdg.de
> -----------------------------------------------------------------------------------
> Geschäftsführer: Prof. Dr. Ramin Yahyapour
> Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger
> Sitz der Gesellschaft: Göttingen
> Registergericht: Göttingen
> Handelsregister-Nr. B 598
> -----------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/occi-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/occi-wg/attachments/20120508/578f8d56/attachment.html>