[occi-wg] Typed Link Kind

[Peter Tröger]

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.