Hi Thomas, The answers to the two questions below seem to be counter to each other. I think if we want to stay true to the RM that we should do this consistently, otherwise there is no reason why we can't deviate in other cases such as the first case below. In fact I would go further and suggest a syntax such as occurrences = <2..*> in dADL and similar in XML.
However, others may not be so keen on this as those starting out with openEHR like to use the built-in development tools in their favourite IDE to generate classes that match the AM/RM and automatically serialize data. This is certainly where I started but soon found limitations in this approach and now have a custom serializer. The thing is, we do want to reduce the entry point to use openEHR and if we require a custom serializer then we make this entry point harder. Regards Heath From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale Sent: Friday, 11 November 2011 4:42 AM To: Openehr-Technical Subject: occurrences and cardinality in ADL, XML, JSON 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/20111114/7204d1e7/attachment.html>
