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.
~~~~~~~~~~ first question: occurrences and cardinality ~~~~~~~~~~~~~~~~
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111110/d9d5e427/attachment.html>
