Rong Chen wrote: > Hi all, > > Sorry for being late on this. > > Currently the Java ADL parser only does the parsing and produces the > AOM objects from ADL (pure parsing). RM based AOM validation is done > in a separate component "archetype-validator", which is now being used > in the CKM (thanks to Sebastian =) > > The archetype-validator has access to the RM classes definitions > through a RMInspector class using Java reflection. More specifically, > the annotations in the Java implementation of RM classes are extracted > and used for RM related validations. The same RM inspection mechanism > is also used for other purpose in the rest of the Java implementation, > e.g. RM data binding between dADL, XML and in-memory RM objects. The > use of Java classes as the computer-readable form of RM definitions is > to minimize the maintenance since the Java classes are supposed to be > up-to-date according to the specs. >
and this is the natural way to do this, in any language... > However, the platform-independent RM definition in dADL proposed by > Tom seems very attractive to me. It could be the single source of the > RM definitions for all major implementations. It clearly has > advantages against platform-specific solutions. Besides, dADL based RM > representation could be used to represent different versions of RM > releases to enable co-existence of different RM versions in the same > runtime system. > just to explain a little: in an idea world, of course, we could have a single beautiful UML model expressed in comprehensible XMI (as opposed to the XMI that we really have) and it would have a guaranteed reliable mapping into all the programming languages and XML-schema. However, this doesn't exist today; the programming languages all have different models of things like inheritance, genericity; most can't implement UML; XSD isn't even OO and has a messy mixture of additive and subtractive semantics over inheritance, plus other problems to do with representing container types....so in the real world, we have to have a plan B. What I have done is a plan B, which seems the best I could do given the messy facts of life! > Regarding the question raised by Tom and David, I would prefer a > generic C_ATTRIBUTE with an optional cardinality attribute. So the > parser will only fill the list and cardinality when necessary without > really checking or guessing if it's a single or multiple attribute > it's dealing with. The necessary validation will only be done in late > stage when the RM definitions is available. The correct use of > C_ATTRIBUTE constraint will reply on the knowledge of underlying RM > classes, which should always be available to the authoring environment > and the EHR runtime systems. > > This does differ from the current design that requires the parser to > decide if the attribute is single-valued or multiple-valued, which in > turn requires an extra keyword (e.g. "container") or mandatory > "cardinality" keyword. In my view, such keyword isn't really necessary > for parsing and doesn't really add any value in this stage. > Nor do I really, unless we accept David Moner's argument that we should be able to do some level of archetype-based parsing without having any access to the reference model. But as I already responded: how did the original archetype author know which attributes were containers and which ones not - which he/she has to know to be able to build the archetype properly - unless the authoring tool knows about the reference model. Simplifying the AOM to only C_ATTRIBUTE would be fine by me; consequences that we would need to think about: the published ISO 13606 standard would be out of date (but it already is due to other changes anyway); are there other tools or scripts etc that rely on the current 1.4 AOM spec structures? - thomas
