In the current ADL 1.4-based XSDs used in openEHR, occurrences, cardinality and existence are expressed as XML elements. We will want to improve this for ADL 1.5 based XML. Now, we don’t want to only take care of XML; we also need to make it work for JSON, and (internally) for dADL - neither of the latter have XML’s ‘attributes’. Many people have asked for more efficient ways of serialising. Here are some ideas for ADL 1.5 XML, JSON etc.
Occurrences and cardinality are proper intervals in the AOM representation. The most simplified object structure (JSON and dADL) for occurrences and cardinality could look as follows (I use dADL & occurrences here):
occurrences = <
lower = <2> -- Integer field
upper = <10> -- Integer field
>
but the upper limit is commonly unbounded, i.e. '*' in typical UML-like syntax. We could do:
occurrences = <
lower = <2> -- Integer field
upper_bounded = <True> -- Boolean field
>
meaning that 3 possible attributes could occur for an occurrences, but only ever 2 at the same time. Or we could make everything into a string:
occurrences = <
lower = <"2"> -- String field
upper = <"*"> -- String field
>
The upside is that the 'upper' attribute now handles both bounded and unbounded values. The downside is that the JSON / dADL parsers would have to do a bit more work to generate the required Interval<Integer> object - since the 'upper' attribute now has to be treated as a little fragment of syntax and checked before being turned into an Integer.
If we were just doing JSON, dADL and other 'proper' OO syntaxes, the first one would be the obvious one. But since we are also targetting XML, we have to think whether it makes more sense to do:
<children node_id="at0005" occurrences_lower="2" **occurrences_upper**="10"> -- xsi:type=C_OBJECT
<rm_type_name>CLUSTER</rm_type_name>
and
<children node_id="at0005" occurrences_lower="2" **occurrences_unbounded**="true"> -- xs:boolean has to support 0/1 and true/false
<rm_type_name>CLUSTER</rm_type_name>
which is the analog of the first approach above, or it could be:
<children node_id="at0005" occurrences_lower="2" **occurrences_upper**="10">
<rm_type_name>CLUSTER</rm_type_name>
and
<children node_id="at0005" occurrences_lower="2" **occurrences_upper**="*">
<rm_type_name>CLUSTER</rm_type_name>
with both attributes defined in the XSD as xs:string. This means that like for JSON/dADL, the XML standard parser only generates strings, and somehting further has to be done to obtain a proper Interval object.
My preference is still to go with the first way of doing things. Do others agree with this? If so, it is what I will implement in the ADL 1.5 workbench.
~~~~~~~~~~~~~ second question:existence ~~~~~~~~~~~~
Existence as an interval can be 0..0 (prohibited, commonly used in templates), 0..1 (optional, typical in the RM) and 1..1 (used in templates and sometimes in archetypes). Now, since archetypes and templates are *constraint* structures, they can only *further* constrain the RM in ADL/AOM 1.5. The only possibilities for this are actually "0..0" and "1..1", so we could collapse existence onto a single Boolean for serialised representation (it could also be a single Boolean in the AOM, but that would be a breaking change, and since we already use Intervals for occurrences and cardinality, it does not seem worth the trouble).
Thus in JSON/dADL it could be:
some_attr = <
existence = <True|False>
>
In XML:
<attributes rm_attribute_name="name"**existence**="true">
....
</attributes>
Now, this is cheating a bit because we are making it look like there is an AOM property 'existence' of type Boolean, but there isn't. Should it be named something else to make this clear? I.e. a pseudo attribute that only exists in serialised format but not in AOM internal format, e.g. 'existence_constraint'? I would favour this. In my current implementation, the serialised format actually has its own object model, and this would have to be true for JSON as well. I think it also makes sense in XML - that there will be a level of classes corresponding to the space-efficient serial form, which are not the same as the internal AOM classes.
thoughts?
- thomas beale
Just when it