[occi-wg] Typed Link Kind

[Boris Parak]

Hi Peter,

> The draft (!) is 3 years old, so this is not surprising. Please, send me some more details about what is wrong with the current mapping approach. I still get requests for making it a real specification, so the demand is there.

the mistake is on our side, not yours. We will fix it in OCCI 1.2.

> As said above, our experience shows that you cannot get away with simple data types only. This is why the DRMAA root spec (language-agnostic, as OCCI core) relies on a struct type as smallest common denominator across multiple languages. They can be mapped to dictionaries (Python / Perl / Ruby), classes (C++, Java) or simple structs (C).

Agreed. The new OCCI Core spec will reflect that.

Cheers, Boris

On Mon, Aug 3, 2015 at 2:08 PM, Peter Tröger <peter at troeger.eu> wrote:
> Dear all,
>
>
>>> seen the unfinished DRMAA<->OCCI document and Peter is using complex
>>> instance attributes, such as:
>>>
>>> < X-OCCI-Attribute: occi.drmaa2.drmsName="Platform LSF"
>>> < X-OCCI-Attribute: occi.drmaa2.drmsVersion={"major":"42",
>>> "minor":"0"}
>>> < X-OCCI-Attribute: occi.drmaa2.drmaaName="Thijs’s OCCI-DRMAA
>>> backend"
>>> < X-OCCI-Attribute: occi.drmaa2.drmaaVersion={"major":"2",
>>> "minor":"17“}
>>>
>
>>> Let's say we have two instance attributes with Hash values:
>>>
>>> occi.test.case.attr1 = { "subattr1": { "value1": "something_here" } }
>>>
>>> occi.test.case.attr1.subattr1 = { "value1" :
>>> "something_different_here" }
>>>
>>
>> From to the discussion in January 2014 (still), we agreed this was not
>> an issue until attribute values are all scalar (string, number,
>> boolean).
>
> Agreed, but flattening the DRMAA data structures into single OCCI attributes is not the right way. Sometimes you need „snapshot“ semantics for sets of values.
>
>> Some thoughts:
>> 1/ DRMAA spec is incorrect wrt actuel OCCI specifications
>
> The draft (!) is 3 years old, so this is not surprising. Please, send me some more details about what is wrong with the current mapping approach. I still get requests for making it a real specification, so the demand is there.
>
>> 2/ do we want to allow complex attribute value types:
>>   Yes -> requires to explicit these types: dictionaries ? list ?
>> tuples ? etc. ? and update all renderings in consequence
>>   No -> DRMAA spec remains incorrect, but how many future spec will be
>> more complex because of that restriction...
>>
>> IMHO: whatever we decide to allow complex attributes in a future Core
>> spec, JSON rendering should not be a limitation for that.
>>
>> -> I support your modification to JSON rendering.
>
> As said above, our experience shows that you cannot get away with simple data types only. This is why the DRMAA root spec (language-agnostic, as OCCI core) relies on a struct type as smallest common denominator across multiple languages. They can be mapped to dictionaries (Python / Perl / Ruby), classes (C++, Java) or simple structs (C).
>
> Best regards,
> Peter.
>
>