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@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@ogf.org
https://www.ogf.org/mailman/listinfo/occi-wg