Non existing constraints: closed or open interpretation?

Pablo Pazos pablo.pazos at
Fri Jul 6 02:43:47 EDT 2018

On Thu, Jul 5, 2018 at 4:12 AM, David Moner <damoca at> wrote:

> El jue., 5 jul. 2018 a las 0:00, Pablo Pazos (<pablo.pazos at>)
> escribió:
>> I know, but my case is not the use of ANY, is that no constraint is
>> defined, it's just empty. The meaning of ANY or * is clear, but I think the
>> meaning of absence of constraints is not so clear. This can affect
>> implementation dramatically, since "open" interpretation is "I can add any
>> content, even if it's not defined by the archetype/OPT", and the "closed"
>> interpretation is "I can only add what's defined by the constraints. One
>> case can be when OPTs have SLOTs, should those slots be resolved by
>> software at runtime or should a specialization of that OPT define reference
>> in the SLOT to have a concrete structure and no other content can be added
>> at runtime.
>> This is the case that troubles me. Because the "open" interpretation
>> means that I can define an empty OPT with just a COMPOSITION, but no
>> COMPOSITION.content definition, and at runtime I can put anything on the
>> content and the instance will be valid against the OPT. Having ANY is a
>> different case, as also having all nodes as optional would be another case
>> (of course respecting the RM optional/required occurrences).
> In my interpretation, not saying anything means no constraining anything,
> including having a path with an empty content. Then the archetype
> definition rules. The problem is not of the template, but a problem of the
> root archetypes used for the template. If the COMPOSITION.content is open
> in the archetype (with the presence of ANY at that point),

As I mentioned on my previous message, my case is not when an ANY / {*}
appears in the ADL, but when there is no definition at all, I'm talking

    COMPOSITION[at0000] matches {
        category matches {
            DV_CODED_TEXT matches {
                defining_code matches {[openehr::433]}

1. I'm not sure if that is interpreted as ANY allowed in

For instance the AE doesn't allow to put a "content matches {*}" there,
which was my interpretation of what you called ANY.

2. If that is not interpreted as ANY allowed (my case), should the
interpretation be a) open or b) closed?

a) at runtime anything can be added to the COMPOSITION instance, so this
works as an ANY allowed :)

b) that definition means the COMPOSITION doesn't have a content and if
content is present, then the instance is invalid, so absence of constraints
means no other nodes can be added there on instances (this case considers
there is no further definition on templates, so templates don't add
structure for "content", it is empty on the template at runtime).

The same questions can be asked about COMPOSITION.context, that some
archetypes don't define and some templates might or not define over
archetypes that don't have it.

I know this is very border case, but just happened to be a real case with a
client :)

> and the template doesn't further constraint it, then you have to accept
> anything from the RM there. It is not a technical interpretation problem,
> but a problem of using a badly designed archetype/template.

Exactly! And related to what is the clinical modeling criteria for
something that the specs and modeling tools allow.

BTW: this is on the clinical list because it is related with clinical
modeling, and IMO this little case needs to be clarified for correct
implementation in software.

> I always say in my courses that archetypes provide a great flexibility and
> power, but you have to accept the consequences of a bad (or incomplete)
> archetype design.
> This interpretation is also coherent with AOM/ADL 2. There the grammar
> won't allow to have those empty definitions in a template.
> --
> David Moner Cano
> Web:
> Twitter: @davidmoner
> Skype: davidmoner
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at

*Ing. Pablo Pazos Gutiérrez*
pablo.pazos at
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter <>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the openEHR-clinical mailing list