Hello,
Which is the field that stores the RM-model-type of data elements ? When I use the ocean instance generator the json contains a field called "@xsi:type", which contains this information. Where in the RM-model itself is this type-field defined ?
Greetings
Georg
That is not a RM attribute, is the class. In XML the xsi:type is needed because for generic types it is not possible to tell the internal structure without specifying the type. That type is the class in the RM.
But if the class is contained within a template instance only within some technical background information and it is not part of the reference model, how can a query mechanism like AQL use this information during query execution ?
How does an AQL query engine know that an archetype based on Composition is a Composition when this link is given in the RM-part of the serialized instance only within the archetype_id of the archetype_details ? From that it could deduced by using the background knowledge of the available archetype definitions that it is in fact a Composition. It would be easier if this would be directly included in the RM-part of a serialized Composition itself.
Or is the class type something one would assume as part of the RM ?
Greetings
Georg
I think short answer is that you need to be aware of the templates/archetypes when executing the AQL. Each node in the archetype has either an atxxxx code or a archetypeid in the archetype node id attribute, that’s how you link both.
In a serialized RM instance there is always a field that lets you know what the class is, for example standardized as discussed before in xml, and as the field _type in json.
If you have this mapped as actual objects in memory in your system, those usually have something in place to determine which class an object is. There’s no need to replace the standard mechanisms with something custom and non-standard.
In other words, yes you need to know the class of a given object, but it is mapped to the mechanism best suited for the used concepts and technology.
Regards,
Pieter Bos
Hi Georg,
Do not confuse the RM model aspects with a particular serialisation format’s aspects.
RM is technology agnostic, it contains a definition of types which can be implemented via most mainstream (OO) programming languages.
Json or XML form of data is a ‘serialisation’ of an object, which is an implementation of an RM type in a language you don’t even have to know about. The type field is a requirement of the serialisation format, so that deserialising code can create the correct instance of the RM types for the correct attributes.
The RM has no need of a type field, it is based on type definitions already. RM uses inheritance (and generics in combination with that) at various locations in the types it defines and this is the reason the type field in the serialised formalism is needed.
It is the same with any mainstream serialisation library that serialises objects which come from a type system that supports inheritance. Nothing specific to openEHR.
Keep this in mind:
RM Definitions → Rm implementation(s) → Data serialisation/deserialisation → (XML/JSON/bla)
The @type field is required at the last two levels.
Cheers
Seref