Some remarks before I will be offline (for a good reason) until June 10. Am 28.06.2012 um 10:03 schrieb Edmonds Andrew (edmo):

After the git detour, inline...

On 26/06/2012 21:25, "Feldhaus, Florian" wrote:

...

A short summary of the changes / open questions: - should the description of locations and category namespaces go to OCCI Core?

A modified version. Some of what's in the current text is more appropriate for an experience document. I would only keep the contents of line 86. The rest can go elsewhere. Also if someone wants to bind 'entity' to a namespace then I can't see why the spec should limit them.

I agree. Maybe Ralf can comment on this as this section is from him.

...

- should the Attribute Definition (or whatever we call it) go to OCCI Core?

Yes, at least what's already there should be expanded upon.

I would appreciate it. I attached a draft class diagram (as pdf and ArgoUML file) how the Core Model could be extended.

...

- how should applicable actions be associated with resources?

Please keep this as close to what we already have in text/plain.

I understand that this should be as close to text/plain as possible. Nevertheless there were some concerns that linking to actions is not nice / clean and that we should fix it. Maybe the others could comment on this. From my point of view linking to applicable actions is a reasonably good way to achieve what we want.

...

In text/plain this is done by linking to them. We discussed to include actions as separate entry in resource but didn't specify how. Do we want to do it? Should the resource contain a full rendering of the action? Should we include an association between Resource and Action in OCCI Core? - should actions be rendered as part of links? Are there scenarios where an action can be triggered on a link? If so, should we include an association between Link and Action in OCCI Core?

Are there? In your view, what's a concrete usage of an action being applied on a link and does OCCI already support an alternative? I remember we once talked about this way back in Brussels using the case of (de)activating a network link via action. This is perhaps one example that might drive the use of link + action.

I can imagine that links could have a state and that actions could be applied to them to change it. Especially if we want to go down the road of having the REST methods GET POST PUT DELETE as actions. As resources are currently (in text/plain) linked with actions, we would have to extend the core model to allow links to have links themselves.

...

- Do we have to specify an attribute type as used within resource and link in contrast to the attribute definition type?

Got an illustrating example?

Categories have attribute definitions / properties (as shown in the attached class diagram). Entities have attributes which are currently not represented in the class model. e.g. Categories have the definition of occi.core.id and Entities have the value of occi.core.id.

...

- Should we limit attributes to just strings? Then we don¹t need the type property and can use the pattern to define arbitrary restrictions on the content. When using true/false and number as well, we might have trouble with applying the pattern and introduce additional complexity.

What does the JSON spec say? Let's not overload JSON semantics.

The JSON spec allows arrays, objects (key/value pairs), strings, numbers and booleans. We agreed not to allow complex types like arrays and objects, as this would bring trouble regarding the attribute definition (e.g. how could we separate in JSON an attribute which has an object as value from an attribute with a longer namespace: one.two = three.four vs. one.two.three = four). As we then restrict the allowed JSON values, we could as well restrict them to strings only. This was suggested at OGF 35 from the audience, as it reduces the overall complexity with regards to pattern matching and the necessity of the type property. From my point of view we could allow number, boolean and string and state that if pattern matching is applied, number and boolean have to be interpreted as strings (e.g. 3 as "3" and true as "true"). One more thing regarding the attribute definitions. Currently it is not clearly distinguishable, if an attribute definition has a attribute name or an attribute property (e.g. type, pattern or description) as they all look the same. This issue could be resolved by requiring all attribute name components to be lowercase (as in text/plain) and make the attribute properties uppercase or at least start with an uppercase letter (e.g. TYPE, PATTERN, DESCRIPTION or Type, Pattern, Description). The JSON spec just requires the names of objects to be strings and thus allows upper and lowercase letters. It just requires that names in objects SHOULD be unique. Cheers, Florian

...

Cheers, Florian

Am 26.06.2012 um 18:13 schrieb Feldhaus, Florian:

...

Hi,

I just updated the OCCI JSON Rendering document in SVN. I also attached the pdf. It includes several points from the discussion during OGF 35. More in the OCCI Call which is taking place right now!

Cheers, Florian

------------------------------------------------------------------------- ------ 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.dehttp://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

Sorry, missed the meeting... Was doing logistics as Colorado is burning to the ground. Overall Comments: I think we need to keep the existing OCCI documents as stable as possible. However, we need to also consider flexibility and usability as part of the overall road map. OCCI separates the scheme information from deployment topologies. Unlike similar approaches, OCCI adopted a two tiered approach for the scheme and does not define a topology. OCCI core, the top level scheme, uses UML to define abstracted OCCI Entities, OCCI Entity Associations and the extension of Entity capabilities via Mixins. OCCI infrastructure, again using UML, extends the OCCI core model to provide the scheme for some IAAS resources. The OCCI rendering specifications map abstractions, defined in the OCCI core and infrastructure specifications, to concrete representations. Where applicable, OCCI Entities, Properties, Actions and Associations are transformed to a data formats, related verbs and functions and any taxonomies required and supported by the rendering's media type. Whether the concrete media type requires properties, attributes, frames, or hyperlinks are details of the concrete type. The abstract OCCI models should not be encumbered by a concrete specification's implementation detail, ie attributes and taxonomy. Other comments are inline. cheers, gary On 6/26/2012 1:25 PM, Feldhaus, Florian wrote:

A short summary of the changes / open questions: - should the description of locations and category namespaces go to OCCI Core?

- should the Attribute Definition (or whatever we call it) go to OCCI Core? See comment above - how should applicable actions be associated with resources? In text/plain this is done by linking to them. We discussed to include actions as separate entry in resource but didn't specify how. Do we want to do it? This depends on the strategy selected for externally defined information associated with a resource. Should the resource contain a full rendering of the action? Should we include an association between Resource and Action in OCCI Core? This was done deliberately to include capabilities of different providers and not exclude providers by inadvertently requiring capabilities that could be protected IP. - should actions be rendered as part of links? Are there scenarios where an action can be triggered on a link? If so, should we include an association between Link and Action in OCCI Core? If memory serves me correctly, links were intended to be a representation of a specific type of association. A resource has Action capabilities. The link is an indicator of a relationship. If the link is becoming an active entity, we should consider it a type of resource. - Do we have to specify an attribute type as used within resource and link in contrast to the attribute definition type? This depends on whether the type is implicitly or explicitly defined in the specification. IMO, since there is no externally defined definition schema associated with JSON, any explicate definition must be defined using an attribute type. - Should we limit attributes to just strings? All JSON values are represented by digits..... Then we don’t need the type property and can use the pattern to define arbitrary restrictions on the content. When using true/false and number as well, we might have trouble with applying the pattern and introduce additional complexity. In JSON all string values are enclosed by double quotes... Can't you detect the double quote as the first and characters in the value ?

Cheers, Florian

Am 26.06.2012 um 18:13 schrieb Feldhaus, Florian:

...

Hi,

I just updated the OCCI JSON Rendering document in SVN. I also attached the pdf. It includes several points from the discussion during OGF 35. More in the OCCI Call which is taking place right now!

Cheers, Florian

------------------------------------------------------------------------------- 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