Re: DADL optional rm-type
Bert Verhees wrote: > Hi, > > I wrote another message before, earlier this week, but that was > addresses to > the Java-list, but I now think it is a problem of specification. > ------------------ > I want to know, is it in all cases possible to guess the rm-type in a > dadl- > construct? I ask this, because the specification says: > > ------------------- > http://www.openehr.org/releases/1.0.1/architecture/am/adl.pdf (page > 23) > The basic design principle of dADL is to be able to represent data in > a way > that is both machineprocessible and human readable, while making the > fewest > assumptions possible about the information model to which the data > conforms. > To this end, type names are optional; often, only attribute names > and values are explicitly shown. > ------------------- > > This spec worries me, because in my opinion, the "guessing" routine > for an rm- > type is hard to write efficient (it contains loops, and will use many > CPU when > processing large amounts of data). > What is more, is it safe? > I say this because, some attributes are optional, maybe there can be > more rm- > types which can be found with a certain attribute. > > Example: > I am thinking about DV_TEXT, it only has one required attribute, > called > "value". > This is also the case for most ID-classes, like HierObjectID. How can > a DADL- > rprocessing routine know what kind of rm-type must be stored? > > Bert, in these cases the type name is needed. It can be left out if your software knows a priori what kind of object a given dADL text is, e.g. an archetype parser knows that the dADL at the top of an archetype is an instance of RESOURCE_DESCRIPTION, so it can proceed on this basis, even though we don't include any typename in the archetype. - thomas _______________________________________________ openEHR-technical mailing list openEHR-technical@openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical