[occi-wg] JSON Rendering

Fri Jun 29 14:39:44 EDT 2012

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" <florian.feldhaus at gwdg.de> 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 at gwdg.de
>>> WWW: www.gwdg.de<http://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
>>>
>>> -------------------------------------------------------------------------
>>> ----------
>>>
>>> <json_rendering.pdf>
>>
>> _______________________________________________
>> 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/20120629/96838c15/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: core_model_new.pdf
Type: application/pdf
Size: 16051 bytes
Desc: core_model_new.pdf
URL: <http://www.ogf.org/pipermail/occi-wg/attachments/20120629/96838c15/attachment-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: core_model.zargo
Type: application/octet-stream
Size: 8140 bytes
Desc: core_model.zargo
URL: <http://www.ogf.org/pipermail/occi-wg/attachments/20120629/96838c15/attachment-0001.obj>