Support non-primitive / complex values such as list / array

[mdutoo]

Supporting OCCI attributes with non-primitive / complex values such as list / array would be useful.

Use case : for instance in the LDaaS use case, Ozwillo Datacore Linked Data projects can be configured with a "dcmp:frozenModelNames" field that is a list of model names.

Workaround (ugly) : serialized ex. (escaped) json within string attribute

Possible solutions :

• simplest i.e. reuse OCCI attributes : add to the Core metamodel a Struct concept that inherits from Categories (so it has attributes) ; and to use it, an instanciable StructDataType data type that is parameterized by a given Struct instance. Problem: this implies that this data type has to be instanciated in OCCI Extension models because they have to refer to Struct-parameterized instances of it. Also add a List data type (maybe optionally it could be also be parameterized by such a Struct instance).
• Ecore datatypes : project them up to runtime. BUT ecore datatypes are not classes. And anyway they may be too many for OCCI-WG to accept it (but this can be solved by putting the problem of primitive types aside and only handle the problem of complex properties i.e. struct / hashmap and list).

Problem analysis :

Here's an analysis of the problem in its various layers, with pointers to status and where it can be followed. It is ongoing, contributions are welcome. BTW should I move it somewhere else ? Where should it be asked on the OCCI ML(s) ? (pointers ?)

D221 Structural model :

• 2.2.3 : "Currently only string, number, and boolean types are supported." => so I guess this was the status quo in previous OCCI versions. BUT D221 should clearly state which OCCI version it is about (1.1 I guess) - it doesn't, neither in the abstract nor the references.
• 3.3 : to go beyond, let's reuse "the extensible data type system provided by EMF". So lists & maps could be EMF types with instanceClassName valued to "java.util.Map" & "java.util.List". Or LinkedHashMap & ArrayList ?? I've defined such OCCI extension using the Studio but have not gone further yet.

OCCI 1.2 :

• spec & comments : https://redmine.ogf.org/projects/editor-pubcom/boards .

OCCI Core 5.1.3 :

• The types supported are “Object”, “List” and “Hash”. But OCCIware Studio's erocci XML generator produces "xs:string" & "xs:int" rather than "string" and "number", so I guess that's only their rendering in XML, especially since in the JSON rendering they are JSON's regular "string" and "number" (see its spec's 3.5.1 or comment). But then how do you get the "official" values above, using a "default" rendering such as the Text one, or are they concepts rather than constants ? And "EMF OCCI" becomes a higher-level definition compared to "standard OCCI" since it can be finer than "Object" but more complete ?

Now let's go on to OCCI Renderings. In general, OCCI Kind attributes should be typed with the corresponding type in the Rendering target format type system, and more importantly, OCCI Resource attributes as well.

OCCI 1.2 Text Rendering :

• JSON-like values, or several lines with the same property having different values, as in comment : https://redmine.ogf.org/boards/33/topics/460

OCCI 1.2 JSON Rendering (I'd say the most important for us) :

• attribute types must be of the regular string, number, boolean JSON type, or in the case of witihin Category / Kind Object, see its spec's 3.5.1 or comment. Or instead of Object can it by other JSON types ex. "Array" ??
• Therefore, erocci (& OCCIware) would provide an added benefit by providing runtime OCCI resource validation against finely EMF-typed definition, compared to what JSON parsers can do, that OCCI backend implementors could merely reuse.
• Beyond, some suggest providing a JSON schema, which OCCIware could generate from .occie as it does for XML ; as a use case, LDaaS has no such schema yet, but could work towards providing or generating one from oasis.meta definitions.
• BTW spec says attributes should be written hierarchically in JSON, following their name's dotted path element hierarchy. This is a problem because in OCCIware we are far from going in this direction (erocci, OCCI impls) and probably don't want to, but this may even cause inconsistency and therefore be removed.

1. same in erocci ?
2. erocci JSON parser : if I understand it, this line says that there can be a resource attribute after a resource attribute object has ended ? But no test of it
3. erocci JSON renderer : seems commented out in https://github.com/erocci/erocci_core/blob/master/src/occi_renderer_json.erl#L207
4. same in erocci-dbus-java ?
5. meaning in dbus-java : List<Variant> and Map<String,Variant> would be enough
6. BUT do we (erocci, OCCI implementors) want to use finer DBus types (i.e. what's returned by myVariant.getType()), taken from the OCCI EMF typing in erocci XML ??

[jeanparpaillon]

I totally agree with you on the need. BTW, 1.2 specs allows for attributes to be 'Object' in JSON, but without any means to define it in schemas.

As any OCCI specs improvement, complex basic datatypes sould have a definition in Core, then renderings.

Let me first writing a proposal for next OCCI meeting (april).

[mdutoo]

Yeah, it's weird (to say the least) that renderings define the attribute type system...