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.