Hi All As ADL only states constraints there is no logical reason to include unbounded. So no constraint expressed = RM max. This is likely to be one or unbounded.
Sent from my phone On 11/11/2011, at 5:11 AM, Thomas Beale <thomas.beale at oceaninformatics.com> wrote: > > 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 Sam: no need for this. > > > > 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 > > Sam: no need for this > > 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? Agree, it could be 0 or 1 > > - thomas beale > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111111/3c173711/attachment.html>
