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
