DADL optional rm-type

Technical (archive)
1

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.

2

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

3

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.

Thanks, Thomas, for your reply.
What I am afraid of, is that, when allowing to NOT specify the rm-type name,
error-prone dadl-files can occur. Possibly an application receives erroneous
dadl's as a form of communication.
Also, when there is no doubt possible, when looking into the broader context,
a routine, it has to analyze this broader context, can be difficult to write,
as I already said before, but the longer I think about it, the more difficult
it seems.

Anyway, in my case, I will not allow not typed dadl's in the first, maybe
later.

Thanks for thinking with me.
Bert

4

Bert Verhees wrote: