[occi-wg] JSON rendering issue

[Florian Feldhaus]

One additional comment:

The attribute definition is always a JSON Object, even if all definitions are omitted. E.g. the following is also an attribute definition (called attribute description format in the JSON spec):
{
   "type": {}
}

The attribute representation always is one of the JSON types string, number or boolean. E.g.
{
   "string": "string“
}
or
{
   "number“: 1
}
or
{
   "boolean“: true
}

Cheers
Florian

Am 19.01.2014 um 19:59 schrieb Florian Feldhaus <florian.feldhaus at gmail.com>:

> Hi,
> 
> as far as I understood this, the issue is to identify if something is describing an attribute or if it is an attribute itself.
> 
> Consider this attribute definition
> {
>    "type": {
>        "required": false,
>        "mutable": false
>    }
> }
> 
> and this attribute representation
> {
>    "type": "string“
> }
> 
> How does an implementation of the JSON Rendering identify which is the attribute definition and which is the attribute representation? It’s quite simple. Only Entities (Resource and Link) have attribute representations and Categories (Kind, Mixin, Action) have attribute definitions. Thus the JSON Parser needs to differentiate between attribute definitions in Categories and attribute representations in Entities.
> 
> The following alternatives have been discussed as part of the OCCI JSON standardization:
> 1.) Usage of the full attribute name (e.g. {"occi.core.id“:{}} instead of {"occi“:{"core“:{"id“:{}}}} ). As the dot has special meaning in OCCI as a namespace separator, we decided to reflect this in the JSON spec. This also allows the usage of the Dot Notation in languages which support it (e.g. JavaScript).
> 2.) Use "attribute-property“ in Categories instead of "attribute“ to state clearly that the attribute property is different from the attribute representation in Entities. We decided against this, as Attribute is (or will soon be) defined in the OCCI Core Model to be the „attribute definition“. Using something like "attribute-representation“ in Entities instead of "attributes" was considered to be confusing. Thus we used „attributes“ both for Categories and for Entities and require the implementor to use the context to identify if they are attribute definitions or attribute representations.
> 
> Cheers
> Florian
> 
> Am 18.01.2014 um 17:10 schrieb Boris Parak <xparak at mail.muni.cz>:
> 
>> Hi Jean,
>> 
>> I don't think this is ambiguous in any way. The definition of string in JSON is:
>> 
>> A string is a sequence of zero or more Unicode characters, wrapped in
>> double quotes, using backslash escapes. [http://www.json.org/]
>> 
>> Hence:
>> 
>> { "default":
>>       { "type": "string" }
>> }
>> 
>> is "default.type" with value 'string'
>> 
>> and
>> 
>> { "default":
>>       "{ \"type\": \"string\" }"
>> }
>> 
>> is "default" with value '{ "type": "string" }'
>> 
>> Or am I missing something?
>> 
>> Cheers, Boris
>> 
>> On Sat, Jan 18, 2014 at 2:40 PM, Jean Parpaillon
>> <jean.parpaillon at free.fr> wrote:
>>> Hi,
>>> I've spent some hours implementing the rendering of resources attributes
>>> as defined in JSON spec and, finally, I think it can _not_ be done that
>>> way because its ambiguous.
>>> Let me give an example:
>>> let the following json document:
>>> { "attributes":
>>> { "com":
>>>   { "example":
>>>     { "default":
>>>       { "type": "string" }
>>>     }
>>>   }
>>> }
>>> }
>>> 
>>> Parsing this document, one can not say if this defines:
>>> - an attribute "com.example" with default value '{ "type": "string" }'
>>> - an attribute "com.example.default" with type "string"
>>> 
>>> Given the interest of the community in JSON rendering and their
>>> implementations, I think we should quickly solve this issue and agree on
>>> a right syntax.
>>> 
>>> Cheers,
>>> --
>>> Jean Parpaillon
>>> Open Source Consultant
>>> Phone: +33 6 30 10 92 86
>>> im: jean.parpaillon at gmail.com
>>> skype: jean.parpaillon
>>> linkedin: http://www.linkedin.com/in/jeanparpaillon/en
>>> 
>>> _______________________________________________
>>> occi-wg mailing list
>>> occi-wg at ogf.org
>>> https://www.ogf.org/mailman/listinfo/occi-wg
>> _______________________________________________
>> occi-wg mailing list
>> occi-wg at ogf.org
>> https://www.ogf.org/mailman/listinfo/occi-wg
>