Although this would work, I think that it would make ADL far less readable and would oblige people to know always the reference model underneath AND their parent archetype (if for some reason the parent archetype is not available then you are completely screwed). Even if you say that people should know very well the model they are defining archetypes for, I think that you would agree with me that they should not be obliged to remember all archetypes on the specialization hierarchy.
This could be even worse for the minimum, as if no constraint is expressed = RM min (and again, also taking into account parent archetype), which is almost always 0 or 1. And not being able to tell at first look if something is not needed is really bad (IMHO). 2011/11/11 Sam Heard <sam.heard at oceaninformatics.com>: > 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 > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >
