# AOM 1.5 - single v multiple attributes
**Category:** [Implementers (archive)](https://discourse.openehr.org/c/implementers-archive/158)
**Created:** 2011-12-16 12:02 UTC
**Views:** 9
**Replies:** 47
**URL:** https://discourse.openehr.org/t/aom-1-5-single-v-multiple-attributes/15110
---
## Post #1 by @thomas.beale
A discussion I think has occurred in the distant past\.\. and it is now
more relevant than before, with the new interest in ADL/AOM by the CIMI
group\.
do we really need C\_SINGLE\_ATTRIBUTE and C\_MULTIPLE\_ATTRIBUTE
descendants of C\_ATTRIBUTE in the AOM? In the reference compiler I have
always had just C\_ATTRIBUTE with an is\_multiple flag\. This flag is set
at object creation time \(or it could be later\), but is independent of
whether the C\_ATTRIBUTE has multiple 'children' \(C\_OBJECTs\)\. This is
because even a C\_ATTRIBUTE representing a single\-valued attribute \(like
OBSERVATION\.protocol\) can have multiple children, each representing an
alternative\. Thus, almost all the logic to do with multiple children is
the same, regardless of the is\_multiple flag\.
No structural logic in my implementation at least is affected by the
is\_multiple flag \- i\.e\. everything to do with managing
C\_ATTRIBUTE\.children is the same, regardless of whether the C\_ATTIRBUTE
object represents a constraint on a single\-valued or a container RM
attribute\.
Qualititatively, the reason for this is: regardless of the attribute
type \(single\-valued or container\), the constraint on the child object/s
is always potentially a number of C\_OBJECTs\. The only difference is in
the actual data \- can the attribute accommodate one or more child
objects? But in constraint\-land, this distinction is nearly invisible\.
So my proposal for AOM 1\.5 is to reduce C\_ATTRIBUTE / C\_SINGLE\_ATTRIBUTE
/ C\_MULTIPLE\_ATTRIBUTE to just C\_ATTRIBUTE\. Having implemented 90% of
ADL/AOM 1\.5, this feels safer to me right now, because I know I can
state all of the class logic \(e\.g\. notion of conformance of a C\_OBJECT
node in a specialised archetype to the counterpart in its parent
archetype\)\.
The impact should be limited to breaking some code in the Java and other
ADL/AOM 1\.4 compilers when being upgraded to ADL/AOM 1\.5; but it should
be a simplification \(I say this because I have never implemented the two
C\_ATTRIBUTE subtypes, not even in the 1\.4 compiler, and there has never
been any pressing need to\.\.\.\.\)\.
In summary: I think it is more appropriate to do this simplification in
the AOM1\.5 spec, because it means that the entirety of the spec is
backed by a real compiler, with fully implemented logic\.
reactions?
\- thomas
---
## Post #2 by @system
I Just implemented this specification\.
Agree\!
Shinji
---
## Post #3 by @system
Thomas,
I agree with you.
This always has been annoying to deal with and is a pretty much useless complication of things.
I believe it will break things in a couple of places, including in my code, but nothing that shouldn't be found and fixed easily.
Sebastian
[details="(attachments)"]
[/details]
---
## Post #4 by @Heath_Frankel3
Hi Thomas,
It may not affect archetype compilers but I think it cause issues with instance validation. From top of my head I think our opt validator use differ logic depending on single and multiple attribute. For example, single is assumed to always a choice and multiple is always a sequence. I don't see how we know this if you drop the differentiation
Interested if Shinji updated his validator and he did this if it was no problem.
Heath
[details="(attachments)"]
[/details]
---
## Post #5 by @thomas.beale
I don't think there should be a problem, because C_ATTRIBUTE still has the following two properties:
- is_multiple: Boolean -- True if the attribute constrained by this C_ATTRIBUTE is a container
- cardinality: CARDINALITY -- non-Void if ... (as above)
The child objects are always in an ordered list, it is just that the order is ignored in the case of C_ATTRIBUTEs for which is_multiple is False.
- thomas
---
## Post #6 by @system
Hi Heath,
2011/12/20 Heath Frankel <[heath.frankel@oceaninformatics.com](mailto:heath.frankel@oceaninformatics.com)>
> Interested if Shinji updated his validator and he did this if it was no problem
It does not matter for me. I am just writing validator and will do it with no problem.
For Ruby implementation, it is easy to adapt such refactoring.
Shinji.
---
## Post #7 by @system
Hi,
The only problem I see here is that the ADL parser won't know when the is_attribute must be set true. Yes, it could know it through the reference model, but I prefer to think that it is not always available. Moreover, a person directly reading the ADL will not distinguish between a single and a multiple attribute.
Some time ago I proposed a solution, that is just to add a reserved keyword in ADL to indicate that the attribute is a container without having to mention or modify the cardinality part. Something as:
CLUSTER matches {
items container matches {*}
}
David
2011/12/20 Thomas Beale <[thomas.beale@oceaninformatics.com](mailto:thomas.beale@oceaninformatics.com)>
---
## Post #8 by @system
The Java Parser currently differentiates this via the presence of cardinality
> `if(cardinality == null) {`
> `attribute = new CSingleAttribute(path, name, existence, children);`
> `} else {`
> `attribute = new CMultipleAttribute(path, name, existence, cardinality,` `children);`
> `}`
This is consistent with what Thomas says below, but probably not as straight-forward as your approach of a distinct keyword.
I can only speak for myself, but I had a look through my code, and while a couple of minor changes will be required, I don't think there would be a big problem without the differentiation.
To be honest, I cannot remember ever seeing the is_multiple flag, neither in the Java Reference Implementation nor the Specs at [http://www.openehr.org/uml/release-1.0.1/Browsable/S.040.1433.36.147Report.html](http://www.openehr.org/uml/release-1.0.1/Browsable/S.040.1433.36.147Report.html)
Sebastian
[details="(attachments)"]
[/details]
---
## Post #9 by @system
2011/12/20 Sebastian Garde <[sebastian.garde@oceaninformatics.com](mailto:sebastian.garde@oceaninformatics.com)>
> The Java Parser currently differentiates this via the presence of cardinality
>
> > `if(cardinality == null) {`
> > `attribute = new CSingleAttribute(path, name, existence, children);`
> > `} else {`
> > `attribute = new CMultipleAttribute(path, name, existence, cardinality,` `children);`
> > `}`
Yes, I know. The question appeared some time ago when thinking in the case when you don't want to constrain the RM cardinality. In that case, the "cardinality" keyword will not be present at the ADL and thus you cannot differentiate between a CSingleAttribute and a CMultipleAttribute (or between setting is_multiple to false or true).
---
## Post #10 by @system
Yes, exactly why I doubt that the above approach is sustainable, at least if we do not allow 'bogus' constraints.
So it seems we can either
- not care at all if it is multiple or single (but then Heath's concerns apply).
- allow [and in fact in some scenarios mandate] bogus constraints
- use a distinct keyword like the one suggested by you.
[Note that this seems to be an orthogonal decision to whether this should then be expressed as C_Attribute or C_Multiple_Attribute and C_Single_Attribute Subclasses, respectively or via a cardinality or is_multiple property]
Sebastian
---
## Post #11 by @thomas.beale
Hi David,
> Hi,
>
> The only problem I see here is that the ADL parser won't know when the is_attribute must be set true. Yes, it could know it through the reference model, but I prefer to think that it is not always available.
that is the assumption we used to used with the previous parser, a few years ago. But in general now there is a reference model description available - why wouldn't there be, in any realistic production context? This means superfluous cardinality constraints are no longer needed just to indicate that the attribute is a container. If for some reason the RM is not available in the tooling, then there is nothing to stop such extra cardinality constraints being added, as they used to be.
> Moreover, a person directly reading the ADL will not distinguish between a single and a multiple attribute.
if they are directly reading the differential source, that's true - the source only expresses constraints in addition to the RM. If they read the flattened view with RM included, they see everything. The following two screen shots are of the same top-level archetype - source form and flattened.
This is the RM-flattened version
Having the RM available (as you have in your tools as well) is not that hard, and it seems to me non-RM enabled tools are a thing of the past. So I guess I am still struggling to see the context in which it makes sense for working without an RM.
- thomas
---
## Post #12 by @thomas.beale
> The Java Parser currently differentiates this via the presence of cardinality
>
> > `if(cardinality == null) {`
> > `attribute = new CSingleAttribute(path, name, existence, children);`
> > `} else {`
> > `attribute = new CMultipleAttribute(path, name, existence, cardinality,` `children);`
> > `}`
>
> This is consistent with what Thomas says below, but probably not as straight-forward as your approach of a distinct keyword.
>
> I can only speak for myself, but I had a look through my code, and while a couple of minor changes will be required, I don't think there would be a big problem without the differentiation.
>
> To be honest, I cannot remember ever seeing the is_multiple flag, neither in the Java Reference Implementation nor the Specs at [http://www.openehr.org/uml/release-1.0.1/Browsable/S.040.1433.36.147Report.html](http://www.openehr.org/uml/release-1.0.1/Browsable/S.040.1433.36.147Report.html)
I probably should clarify one thing: with no hint in the archetype as to whether a given attribute is single or multiple, the parser does have to use the RM. This added a few lines of code to my parser. It seems a small price to pay for 'clean' archetypes, and as a bonus, the parser now detects many other errors earlier.
- thomas
c_attr_head: V_ATTRIBUTE_IDENTIFIER c_existence c_cardinality
{
rm_attribute_name := $1
if not object_nodes.item.has_attribute (rm_attribute_name) then
if rm_schema.has_property (object_nodes.item.rm_type_name, rm_attribute_name) then
**bmm_prop_def := rm_schema.property_definition (object_nodes.item.rm_type_name, rm_attribute_name)**
if **bmm_prop_def.is_container** then
create attr_node.**make_multiple** (rm_attribute_name, $2, $3)
c_attrs.put (attr_node)
object_nodes.item.put_attribute (attr_node)
elseif $3 = Void then
create attr_node.**make_single** (rm_attribute_name, $2)
c_attrs.put(attr_node)
object_nodes.item.put_attribute(attr_node)
else -- error - cardinality stated, but on a non-container attribute
abort_with_error("VSAM2", <>)
end
else
abort_with_error("VCARM", <>)
end
else
abort_with_error("VCATU", <>)
end
}
> absolute_path c_existence c_cardinality
{
..
}
;
---
## Post #13 by @Heath_Frankel3
Thomas,
My issue here is needing to know if attribute children are a choice or a sequence. It is not true that children are always ordered, this depends on the cardinality isordered flag. If this defaults to false when cardinality is null then perhaps it will be ok.
My concern is the implicit rules necessary to interpret the resulting model. Currently it is explicit via the type and the AOM xsd uses this allowing no special processing.
If we had a grouping construct allowing choice vs sequence as per xsd then we would have an explicit constraint without the need for c_attribute sub types.
My greatest concern is the lack of backward compatibility, this is a breaking change.
If this was a v2 proposal I would not be raising this, part for me a 1.5 release should be backward compatible with 1.4.
Heath
---
## Post #14 by @system
Hi Thomas,
I think we have already discussed this several times :-)
> > Moreover, a person directly reading the ADL will not distinguish between a single and a multiple attribute.
>
> if they are directly reading the differential source, that's true - the source only expresses constraints in addition to the RM. If they read the flattened view with RM included, they see everything. The following two screen shots are of the same top-level archetype - source form and flattened.
I'm thinking in the first case, reading a differential ADL without specific tools, just a plain text editor.
> This is the RM-flattened version
>
> Having the RM available (as you have in your tools as well) is not that hard, and it seems to me non-RM enabled tools are a thing of the past. So I guess I am still struggling to see the context in which it makes sense for working without an RM.
We are absolutely in favour of having the RM available for advanced tooling, but we cannot forget the case when it is not possible. All systems cannot be aware of all possible models, but at least they should be able to work at a pure archetype level. In other words, I'm in favour of having the most basic tools (ADL parser, ADL viewer) that are capable of working with "standalone" archetypes. ADL parsers should work solely at the syntax level and not depend on other semantics.
I don't know about Eiffel, but seeing your code, what happens if you try to parse an ADL with a misspell of an attribute name? If you cannot retrieve it from the RM, you cannot finish the parsing to correct it directly in the tool.
Or if we go beyond, what happens if you try to parse an ADL of non-available RM? For example, a CDA archetype (the next example is not completely accurate since it still maintains the cardinality information):
POCD_MT000040_Person[at0079] occurrences matches {0..1} matches { -- POCD_MT000040_Person
name existence matches {0..1} cardinality matches {0..*; unordered; unique} matches {
PN[at0081] occurrences matches {0..1} matches { -- Person Name
family existence matches {0..1} cardinality matches {0..2; ordered; unique} matches {
En_family[at0083] occurrences matches {0..1} matches { -- First surname
---
## Post #15 by @thomas.beale
> Hi Thomas,
>
> I think we have already discussed this several times :-)
yep - I'd like to find a conclusion!
> > > Moreover, a person directly reading the ADL will not distinguish between a single and a multiple attribute.
> >
> > if they are directly reading the differential source, that's true - the source only expresses constraints in addition to the RM. If they read the flattened view with RM included, they see everything. The following two screen shots are of the same top-level archetype - source form and flattened.
>
> I'm thinking in the first case, reading a differential ADL without specific tools, just a plain text editor.
I wonder how many people will really do this?
> > Having the RM available (as you have in your tools as well) is not that hard, and it seems to me non-RM enabled tools are a thing of the past. So I guess I am still struggling to see the context in which it makes sense for working without an RM.
>
> We are absolutely in favour of having the RM available for advanced tooling, but we cannot forget the case when it is not possible. All systems cannot be aware of all possible models, but at least they should be able to work at a pure archetype level.
Hm... this is something I find a bit strange - what use can an archetype be with no access at all to its reference model? Well, it's true that in a design context like CKM, it could be useful to view the archetypes to look at their clinical design, but I find it hard to believe that the kind of people who would do that - clinical people, surely - would want to look at raw ADL, especially differential ADL. I think they are more likely to look at the mindmap or HTML, and all that is generated.
> In other words, I'm in favour of having the most basic tools (ADL parser, ADL viewer) that are capable of working with "standalone" archetypes. ADL parsers should work solely at the syntax level and not depend on other semantics.
I have to admit that was my view some years ago. Then I got sick of a) not being able to properly validate anything - e.g. does OBSERVATION have a 'data' attribute or not? and b) having to include spurious constraints that didn't say anything, except to signal attribute multiplicity.
> I don't know about Eiffel, but seeing your code, what happens if you try to parse an ADL with a misspell of an attribute name? If you cannot retrieve it from the RM, you cannot finish the parsing to correct it directly in the tool.
you get the relevant error, then you go edit the archetype at the line number indicated, and fix the attribute name. The RM validation is in the phase 2 validator these days. Multi-phase validation is certainly needed in order to allow the author to fix RM errors in an otherwise correct archetype.
> Or if we go beyond, what happens if you try to parse an ADL of non-available RM? For example, a CDA archetype (the next example is not completely accurate since it still maintains the cardinality information):
in the current tool, you can't. I could probably re-instate a mode like that, but .... I am not sure I see the point. Let's say I have the archetype below, my first instinct is to want to know what is in the reference model, such as in the following view (using an openEHR archetype):
what can I do with this CDA archetype that is (by definition) a set of partial constraints on a model I don't have access to?
- thomas
---
## Post #16 by @yampeku
Well, I have been able to define a complete reference model \(MedXML
MML\) by defining the archetypes of all the concepts defined on the
model documentation\. So I have no reference model to check things at
first place\.
For LinkEHR, the reference models are \(a set of\) archetypes\. You can
define new archetypes through specialization\.
So at least I need to be able to parse archetypes without reference model :\)
---
## Post #17 by @system
Now is when this is getting interesting :-)
> > > > Moreover, a person directly reading the ADL will not distinguish between a single and a multiple attribute.
> > >
> > > if they are directly reading the differential source, that's true - the source only expresses constraints in addition to the RM. If they read the flattened view with RM included, they see everything. The following two screen shots are of the same top-level archetype - source form and flattened.
> >
> > I'm thinking in the first case, reading a differential ADL without specific tools, just a plain text editor.
>
> I wonder how many people will really do this?
I don't know, but it is not our role to decide what people can or cannot do, or to obligate them to use specific tools. What I miss here is a bit of coherence. If we assume that archetypes are always edited with specific tools, why are we bothering about ADL to be readable or not? Why do we use structures like domain types at the ADL to ease reading? The tool could hide all these things....
> > > Having the RM available (as you have in your tools as well) is not that hard, and it seems to me non-RM enabled tools are a thing of the past. So I guess I am still struggling to see the context in which it makes sense for working without an RM.
> >
> > We are absolutely in favour of having the RM available for advanced tooling, but we cannot forget the case when it is not possible. All systems cannot be aware of all possible models, but at least they should be able to work at a pure archetype level.
>
> Hm... this is something I find a bit strange - what use can an archetype be with no access at all to its reference model? Well, it's true that in a design context like CKM, it could be useful to view the archetypes to look at their clinical design, but I find it hard to believe that the kind of people who would do that - clinical people, surely - would want to look at raw ADL, especially differential ADL. I think they are more likely to look at the mindmap or HTML, and all that is generated.
All that stuff can mostly be generated without knowing nothing about the RM. So, why to require it at the previous step (during the parsing)?
> > In other words, I'm in favour of having the most basic tools (ADL parser, ADL viewer) that are capable of working with "standalone" archetypes. ADL parsers should work solely at the syntax level and not depend on other semantics.
>
> I have to admit that was my view some years ago. Then I got sick of a) not being able to properly validate anything - e.g. does OBSERVATION have a 'data' attribute or not? and b) having to include spurious constraints that didn't say anything, except to signal attribute multiplicity.
Again, here you are mixing two different processes. One thing is the archetype parsing and validation, following the AOM rules and ADL syntax. The archetype should be parsed and syntactically validated to instantiate the AOM. Then, a different thing is to validate it against a RM in a second phase. In fact this is not different from the typical steps of any compiler.
> > I don't know about Eiffel, but seeing your code, what happens if you try to parse an ADL with a misspell of an attribute name? If you cannot retrieve it from the RM, you cannot finish the parsing to correct it directly in the tool.
>
> you get the relevant error, then you go edit the archetype at the line number indicated, and fix the attribute name. The RM validation is in the phase 2 validator these days. Multi-phase validation is certainly needed in order to allow the author to fix RM errors in an otherwise correct archetype.
And is it not better to do this correction inside the tool, in a guided environment? Here (absolutely yes), guided by a reference model.
David
---
## Post #18 by @thomas.beale
> >
>
> I don't know, but it is not our role to decide what people can or cannot do, or to obligate them to use specific tools. What I miss here is a bit of coherence. If we assume that archetypes are always edited with specific tools, why are we bothering about ADL to be readable or not? Why do we use structures like domain types at the ADL to ease reading? The tool could hide all these things....
well I don't think we are obliging anyone to use specific tools. In my view, the reason for ADL being human readable is to enable a relatively small number of people - generally not end users - to understand the semantics of the formalism, in the same way that certain people understand OWL by using/studying OWL-abstract resources. So I think ADL source is useful for:
- learning / teaching / self-education - typically by some software developers, educators, standards people
- understanding archetypes in debugging / testing - knowing what the archetype really says, in case a tool seems to be lying to you.
These people are usually doing something specialised, and understand the formalism properly (or are learning it). I don't think many end users are going to read ADL, other than educators/software developers/theorists. I don't think this requirement means that the archetype has to stand alone as a modelling construct. I say this mainly because the very definition of an archetype is about constraining an information model, so I am not sure that what it means to have one with no access to the information model.
For example the node
ELEMENT [at0004] -- systolic pressure
means... what? If you don't know what an ELEMENT is? So while ADL is designed to be readable, that alone doesn't tell you what it means if you don't know what the RM references (class names & attribute names) mean...
> > > > Having the RM available (as you have in your tools as well) is not that hard, and it seems to me non-RM enabled tools are a thing of the past. So I guess I am still struggling to see the context in which it makes sense for working without an RM.
> > >
> > > We are absolutely in favour of having the RM available for advanced tooling, but we cannot forget the case when it is not possible. All systems cannot be aware of all possible models, but at least they should be able to work at a pure archetype level.
> >
> > Hm... this is something I find a bit strange - what use can an archetype be with no access at all to its reference model? Well, it's true that in a design context like CKM, it could be useful to view the archetypes to look at their clinical design, but I find it hard to believe that the kind of people who would do that - clinical people, surely - would want to look at raw ADL, especially differential ADL. I think they are more likely to look at the mindmap or HTML, and all that is generated.
>
> All that stuff can mostly be generated without knowing nothing about the RM. So, why to require it at the previous step (during the parsing)?
some of those views can be generated, but only if the archetype has already been validated, including against the RM. You can't generate any view that includes RM elements in it though, and clinicians have been screaming to have that in the modelling tools and CKM. It is now (sort of) in CKM. The reason they need it is because they want a 'total view' of the data. If they can't see RM elements, they start to think those items have not been included.
In the end, archetypes and templates define an object structure + variants; but you can only see the full object structure if you have the RM there as well. Some archetypes are very small, and define very few constraints; on their own, I find it hard to understand what use they are.
> > > In other words, I'm in favour of having the most basic tools (ADL parser, ADL viewer) that are capable of working with "standalone" archetypes. ADL parsers should work solely at the syntax level and not depend on other semantics.
> >
> > I have to admit that was my view some years ago. Then I got sick of a) not being able to properly validate anything - e.g. does OBSERVATION have a 'data' attribute or not? and b) having to include spurious constraints that didn't say anything, except to signal attribute multiplicity.
>
> Again, here you are mixing two different processes. One thing is the archetype parsing and validation, following the AOM rules and ADL syntax. The archetype should be parsed and syntactically validated to instantiate the AOM. Then, a different thing is to validate it against a RM in a second phase. In fact this is not different from the typical steps of any compiler.
sure - that's how the reference compiler works as well. But if we want to do early compiler stages with no RM available, the cost is adding spurious non-constraints - extra syntax. So let's say we do that, and now we get to phase 3 validation (or whatever it is in each tool) and you get a mismatch between that syntax marker for multiple-valued attributes, and what the RM says? Now we have a new source of errors we did not have before.
So the question is (in my mind at least): is it worth having that, so we can perform some basic parsing and partial validation of an archetype? Consider also:
- the question of how the syntax marker got there in the first place: presumably with an editor. All editors of the future will obviously be RM-aware, because every user of the current tools that are not RM-aware complains about about (and rightly so). So if we assume editors are RM-aware, why would we assume compilers are not RM-aware?
- I think it is also reasonable to assume that there will only be a small number of good quality compilers in the end, so here again, it seems hard to see why they would not all be RM-enabled.
- If you agree that the RM is likely to be present in a compiler, even for say stage 3 or 4 validation, then it is available.... and it can be used at any point. Why not use it earlier on to detect some basic errors as well?
A marker for an attribute being multiple or single is not the only thing you have to have in archetypes to correctly express attributes. You also have to have [at-codes] on child objects of container attributes. But if there is only one child under a particular attribute in a particular archetype, then it still has to be marked with an at-code, whereas under a single-valued attribute it doesn't. So what happens if the attribute is marked 'container' but the child object(s) do not have at-codes? The only way to deal with that properly is with the RM, because you have to determine what kind of attribute it really is before you can say whether the at-codes have to be there or not. So yes, you could ignore it at that stage in parsing and generate AOM objects, but they are likely to be wrong AOM objects.
These are some of the reasons I find it hard to see much value in a specific marker for container attributes, or doing much parsing of archetypes with no RM present.
I would be interested to know what some others think (I know what I think, and what the UPV group thinks;-)
- thomas
---
## Post #19 by @thomas.beale
>
> Thomas,
> My issue here is needing to know if attribute children are a choice or
> a sequence\. It is not true that children are always ordered, this
> depends on the cardinality isordered flag\. If this defaults to false
> when cardinality is null then perhaps it will be ok\.
>
what I meant was that in physical representation the children are always
ordered, so the question of whether the order is significant in validity
then requires looking at the Cardinality is\_ordered flag\. I must admit I
don't know what the UML default for that is, and probably we should
state the same default \(one would guess 'not ordered'?\)\.
> My concern is the implicit rules necessary to interpret the resulting
> model\. Currently it is explicit via the type and the AOM xsd uses this
> allowing no special processing\.
>
it is still explicit, just via attributes rather than the type\.
> If we had a grouping construct allowing choice vs sequence as per xsd
> then we would have an explicit constraint without the need for
> c\_attribute sub types\.
>
well this is a different problem, which the group construct addresses,
to allow choice\-of subgroups within multiple attribute children\.
> My greatest concern is the lack of backward compatibility, this is a
> breaking change\.
>
it is a small breaking change yes, but from what I can see the breakages
are small, and the gain in clarity is worthwhile\. From your point of
view, where is the main impact, and is it too great to deal with?
\- thomas
---
## Post #20 by @thomas.beale
ok, but the reference model is there \- you have just chosen archetypes
to represent it \(we did think about that in the past as well\)\. It's a
design decision, but it doesn't mean you have no RM present\.
\- thomas
---
## Post #21 by @Seref
Hi Tom,
Since you've asked about what others think; I'll take the liberty of sharing my thoughts.
Initially I was not happy about the dependence on existence of a computable RM just to be able to parse ADL. For me, it meant either waiting for Rong to handle it in the parser, or find a way of walking around this requirement (I am lazy).
However, the need for computable RM is not specific to adl parsing only. Unless you want to hand code a large amount of functionality, you need to deal with this at a couple of points. For example, when serialized RM data arrives over the wire (XML, JSON, YAML, Protocol Buffers, you name it), you may have to handle assignment of a concrete class instance to an abstract class typed field. (my usual example). You have to know the relationship of RM types to do that. You can hand code it, or you can use a computable model
In an archetype/template editor, you may like to introduce some smart features (such as auto complete, or suggestions) or you may simply need to disable various options based on the context. For example, a contaner node in an archetype will have a type, and only that type or its subtypes (for specialization of that node in a t-archetype) should be allowed in the tool. Again, the tool will need to process the RM type info. You can again hand code it, or use a computable model.
As an implementer discovers other use cases, he or she will see that RM must be computable. I don't think handcoding RM related functionality is something that can be managed. AOM is one of the things that makes openEHR better than the alternatives, and having a different approach to one level of two level modelling really does not make sense; so both levels should be computable, and also use cases require it to be so.
So; if I'm going to have to process RM at more than one point, it is not such a big deal if I have to do it in the parser. I know that one way or another this functionality is going to be necessary, so why try to avoid it at one point, when you know you'll somehow deal with it anyway?
regards
Seref
2011/12/21 Thomas Beale <[thomas.beale@oceaninformatics.com](mailto:thomas.beale@oceaninformatics.com)>
---
## Post #22 by @system
> I would be interested to know what some others think (I know what I think, and what the UPV group thinks;-)
Yes, I think that is necessary :-)
Let me just make two final comments:
Regarding the proposal of a single object for attributes, that was the original topic of the thread, I just want to clarify that we completely agree. It is a much better design.
Regarding the other discussion, I'll try to describe it in simple words to clarify it. We have a model (the AOM) and a serialization of that model (the ADL). The question is whether the transition between them can or should be done independently or if we need to put in the middle the RM to help in the process.
David
---
## Post #23 by @yampeku
actually it does mean that, I am parsing the ADL without a reference
model \(currently I don't need know anything about it\)\. Then when it is
loaded, I have my reference model\. We decided to use a format to
represent reference models that could take advantage of current tools
\(parsers, serializers\.\.\.\), instead of defining our own format :\)
---
## Post #24 by @thomas.beale
See the other bit of this thread: the reason (I think) you think we don't need any RM is because you do in fact have it, just cunningly expressed as archetypes. But it is there.
- thomas
---
## Post #25 by @Seref
2011/12/21 Thomas Beale <[thomas.beale@oceaninformatics.com](mailto:thomas.beale@oceaninformatics.com)>
>
> > > I would be interested to know what some others think (I know what I think, and what the UPV group thinks;-)
> >
> > Yes, I think that is necessary :-)
> >
> > Let me just make two final comments:
> >
> > Regarding the proposal of a single object for attributes, that was the original topic of the thread, I just want to clarify that we completely agree. It is a much better design.
> >
> > Regarding the other discussion, I'll try to describe it in simple words to clarify it. We have a model (the AOM) and a serialization of that model (the ADL). The question is whether the transition between them can or should be done independently or if we need to put in the middle the RM to help in the process.
>
> See the other bit of this thread: the reason (I think) you think we don't need any RM is because you do in fact have it, just cunningly expressed as archetypes. But it is there.
This is what I (more or less) did in Opereffa, but it bit me a little bit further down the road :)
---
## Post #26 by @system
> See the other bit of this thread: the reason (I think) you think we don't need any RM is because you do in fact have it, just cunningly expressed as archetypes. But it is there.
Yes, but not for the parsing.
---
## Post #27 by @Heath_Frankel3
Thomas,
I think the point that David is making is that we probably want some separation of concerns when it comes to ADL (or AOM in general ) parsing. A parsing operation to generate the AOM and a separate RM validation operation allows better reuse
I can use your RM validator after deserialising an XML archetype and David can use the Java ADL parser for the apply his AOM based RM validator.
The benefits of loosely coupled components.
Heath
---
## Post #28 by @system
I am not so sure that this is true. And same goes for the current Java Parser I believe:
The RM is not required for parsing, just for subsequent validation.
I think that this separation of concerns makes a lot of sense and has served us well so far.
Enforcing a tighter coupling here for this - in the grand scheme of things - minor issue, feels wrong to me.
Likely most of us agree that we can do great things when we have a computable RM - but I would argue that the real value of this comes well after parsing.
Sebastian
---
## Post #29 by @system
Hi\!
> For LinkEHR, the reference models are \(a set of\) archetypes\. You can
> define new archetypes through specialization\.
The ability to express the RM using the AM can provide pretty elegant
\(recursive?\) solutions \(like the one under the hood in LinkEHR\-Ed I
believe\), so whatever we change in the AM it would be nice if this
ability is kept somehow\. But I guess this is not changed by having an
is\_multiple attribute on one class instead of having three separate
classes, right?
Also being able to parse archetypes into AOM object\-trees as a first
step irrespective of what RM was used is valuable, but does the
suggested change really change that possibility? Archetype format
conversion utilities doing ADL<\->JSON<\->YAML is an example\. \(And yes
of course an RM of some kind is necessary to make full use of the AOM
in many other cases\.\)
Best regards,
Erik Sundvall
erik\.sundvall@liu\.se http://www.imt.liu.se/~erisu/ Tel: \+46\-13\-286733
---
## Post #30 by @yampeku
I don't think there is any problem to have the attribute instead of 3
classes\. It would be even simpler and clearer to test things
\(instanceof vs checking if an attribute is true or not\)\. The only
problem I see is what is needed to put a value to that attribute from
ADL :\)
---
## Post #31 by @thomas.beale
it's a great idea, and we thought seriously about it for some time\. But
\.\.\. ADL doesn't represent everything that is needed in a proper object
model\.\.\. including generic types, open/closed generic parameters,
multiple inheritance and a few other things\.
\- thomas
---
## Post #32 by @thomas.beale
> ```
> Hi!
>
>
> ```
>
> > ```
> > For LinkEHR, the reference models are (a set of) archetypes. You can
> > define new archetypes through specialization.
> >
> > ```
>
> ```
> The ability to express the RM using the AM can provide pretty elegant
> (recursive?) solutions (like the one under the hood in LinkEHR-Ed I
> believe), so whatever we change in the AM it would be nice if this
> ability is kept somehow. But I guess this is not changed by having an
> is_multiple attribute on one class instead of having three separate
> classes, right?
> ```
see other post - ADL/AOM don't do quite a few things that a normal object meta-model does (which is what you need if you want to express a full OO IM), including multiple inheritance; everything relating to generic types; specific OO rules of redefinition; abstract v concrete classes; computed and functional properties... and so on.
> ```
> Also being able to parse archetypes into AOM object-trees as a first
> step irrespective of what RM was used is valuable, but does the
> suggested change really change that possibility? Archetype format
> conversion utilities doing ADL<->JSON<->YAML is an example. (And yes
> of course an RM of some kind is necessary to make full use of the AOM
> in many other cases.)
> ```
no, I think we agree on the suggested change (reduce the complexity of the AOM to the following). The thing I am having trouble with is that if you parse with no RM present, you need to add some kind of marker to distinguish single-valued v multiple-valued (container) classes. I can't see the post right now, but David proposed something like a 'container' keyword.
- thomas
---
## Post #33 by @thomas.beale
> Thomas,
> I think the point that David is making is that we probably want some separation of concerns when it comes to ADL (or AOM in general ) parsing. A parsing operation to generate the AOM and a separate RM validation operation allows better reuse
> I can use your RM validator after deserialising an XML archetype and David can use the Java ADL parser for the apply his AOM based RM validator.
> The benefits of loosely coupled components.
> Heath
But you can do that right now. If you were to use the reference compiler components, you could easily use:
- parser*: syntax validation, some basic RM checking, generate AOM objects
- phase 1 validator*: validate languages, slots, slot-fillers, basic ontology validation
- phase 2 validator*: (validation requiring flat parent): validate constraint structure, main RM validation, further ontology validation
- flattener: flatten child archetype onto parent
- phase 3 validator: (validation on flattened archetype): VACMC validation
The starred components use the RM to do some work.
This compiler is not particularly an example of great design; it just implements the specification in a rigorous way so others can test against it. But you could deploy any of the above phases separately. If I was to supply any of them to you as a software component, I would include the RM schema component as well.
A version of the parser could be made with no access to the RM, you are back to creating possibly broken AOM objects. I still think we need to address the following problems:
> sure - that's how the reference compiler works as well. But if we want to do early compiler stages with no RM available, the cost is adding spurious non-constraints - extra syntax. So let's say we do that, and now we get to phase 3 validation (or whatever it is in each tool) and you get a mismatch between that syntax marker for multiple-valued attributes, and what the RM says? Now we have a new source of errors we did not have before.
>
> So the question is (in my mind at least): is it worth having that, so we can perform some basic parsing and partial validation of an archetype? Consider also:
>
> - the question of how the syntax marker got there in the first place: presumably with an editor. All editors of the future will obviously be RM-aware, because every user of the current tools that are not RM-aware complains about about (and rightly so). So if we assume editors are RM-aware, why would we assume compilers are not RM-aware?
>
> - I think it is also reasonable to assume that there will only be a small number of good quality compilers in the end, so here again, it seems hard to see why they would not all be RM-enabled.
> - If you agree that the RM is likely to be present in a compiler, even for say stage 3 or 4 validation, then it is available.... and it can be used at any point. Why not use it earlier on to detect some basic errors as well?
>
> A marker for an attribute being multiple or single is not the only thing you have to have in archetypes to correctly express attributes. You also have to have [at-codes] on child objects of container attributes. But if there is only one child under a particular attribute in a particular archetype, then it still has to be marked with an at-code, whereas under a single-valued attribute it doesn't. So what happens if the attribute is marked 'container' but the child object(s) do not have at-codes? The only way to deal with that properly is with the RM, because you have to determine what kind of attribute it really is before you can say whether the at-codes have to be there or not. So yes, you could ignore it at that stage in parsing and generate AOM objects, but they are likely to be wrong AOM objects.
>
> These are some of the reasons I find it hard to see much value in a specific marker for container attributes, or doing much parsing of archetypes with no RM present.
- thomas
---
## Post #34 by @Heath_Frankel3
Yes, the problem is is_multiple is not an attribute but a property derived from the existence of cardinality. It is my understanding that cardinality will become optional in AOM 1.5 due to the assumed knowledge of an RM or parent archetype. Now this necessary to support specialisation and templates but will cause ambiguity with parsing base models. From an XML perspective I would prefer a type over an attribute but ADL doesn't have the same means of making it explicit.
Heath
---
## Post #35 by @thomas.beale
I still don't think all the questions I raised are yet addressed, but in any case, I hope we can agree that the current draft of the AOM constraint model is ok? The debate we are having here is whether we add something to ADL (and by implication, all other serialised forms) that informs the parser of whether an attribute node is single- or multiple-valued (i.e. something that can be directly used to set the C_ATTRIBUTE.is_multiple flag).
If we agree on this, then I will proceed with ongoing work with the AOM. If the community direction is to want an extra flag in ADL then we can deal with it separately.
Seem reasonable?
- thomas
---
## Post #36 by @thomas.beale
all,
I want to get back to the issue of whether we mark (in ADL) multiple-valued attributes and solve it. As I said in a post aeons ago (i.e. before Christmas) I was not convinced by the arguments in favour of needing to be able to parse ADL archetypes in a standalone mode, i.e. with no RM present. But I could be wrong or not understanding the arguments. In addition I have found an argument that I think persuades me (but might not others!).... anyway, here are the arguments FOR adding an indicator that I think I heard so far, with my responses:
- the parser (at least initial stage that generates an AOM structure) will be simpler with no RM required
- TB: this is clearly true, but does it matter? The added complexity is pretty low, at least in the reference parser.
- we should be able to generate an AOM structure even if the RM details of the model are wrong
- TB: I am struggling to see the utility of this... what's the use of an AOM structure that might contain basic errors? Assuming one of the following stages of the parser does do the full RM check (mine does it in phase 2 validation) then the question is: between the point of having generated an AOM, but before having done the full RM check, what useful thing could you do with the AOM structure? One obvious answer is: display it in some way... but why? Maybe there are reasons that make sense, I just can't see them yet.- we should be able to parse an archetype if there is no representation of the RM available
- TB: this implies that you could do stage 1 parsing, i.e. generate a raw AOM structure.... but what would you do with it. Again, the most obvious answer is probably to display it. Now I can see some utility here, since the basic node visualisation (like AWB and LinkEHR do) is easier to understand than raw ADL, especially for large archetypes, and it would mean that a user could get their mind around some new kind of archetype in a basic way, even with no RM availability at all.
I think that was it. I still struggle with solid reasons for point #2 above.. until just today, when I was looking at the structure of the compiler for parsing generated ADL flat files, e.g. flattened archetypes (.adlf files from the AWB) and operational archetypes (.opt files). Most people seem to want an XML format for OPTs (that's what all Ocean's software uses, and I believe most other implementers have done the same). However, some people (at least Rong and Seref) have voiced interest in an ADL representation of OPT. This is already available in the AWB (there are test EHR Extract archetypes for it). Now, if this ADL format OPT was saved to a file and parsed later on, one thing we know is that it must be 100% correct, assuming no software bugs in the ADL-OPT serialiser. So processing it with the full heavy-weight ADL compiler is unnecessary; it could be parsed to AOM structures (again, as long as the parser has no bugs, this AOM tree will be correct) and there is likewise no need for RM checking. This 'guaranteed-correct' AOM structure could be useful for all kinds of things, and it is obviously nice to be able to generate it as fast as possible.
Thoughts on this?
- thomas
---
## Post #37 by @system
Hi Thomas,
All the arguments mentioned are of course of relative importance. Your answers to them (and with which I could easily agree) are from a final user perspective, but not from a coherent specification design perspective. You say that you can't imagine the utility of parsing without RM, and the answer is that you shouldn't matter about it. Maybe someone designs a web based editor and the ADL parser is at the client side while the RM remains at the server. I don't know and I don't mind. The RM-aware ADL parser can be part of a technical implementation specification or best practices for implementers, but you cannot bring that requirement to the model specifications.
The really important point to be solved is that if ADL is the serialized representation of the AOM it must be able to represent all of its properties (and the way back). If a mark for is_multiple is not added in ADL, it will be the only property of the AOM that cannot be instantiated from a standalone ADL. In other words, ADL will not be a correct specification for its theoretical scope. That is clearly an exception (if not an error) and a source of future limitations.
David
2012/1/9 Thomas Beale <[thomas.beale@oceaninformatics.com](mailto:thomas.beale@oceaninformatics.com)>
---
## Post #38 by @Peter_Gummer1
Thomas Beale wrote:
> • we should be able to generate an AOM structure even if the RM details of the model are wrong
> • TB: I am struggling to see the utility of this\.\.\. what's the use of an AOM structure that might contain basic errors? Assuming one of the following stages of the parser does do the full RM check \(mine does it in phase 2 validation\) then the question is: between the point of having generated an AOM, but before having done the full RM check, what useful thing could you do with the AOM structure? One obvious answer is: display it in some way\.\.\. but why? Maybe there are reasons that make sense, I just can't see them yet\.
It would be useful to be able to display an AOM structure that is invalid with respect to the RM\. For example, an archetype editing tool that validates against the RM during parsing would presumably be incapable of loading the archetype and would throw an incomprehensible parser error at the user\. Not nice\. What would be much better would be if the editor could display the AOM structure, and then highlight the RM validation errors in a way that made it easy for the user to find and correct them\.
\- Peter
---
## Post #39 by @thomas.beale
> ```
> Thomas Beale wrote:
>
> ```
>
> > ```
> > • we should be able to generate an AOM structure even if the RM details of the model are wrong
> > • TB: I am struggling to see the utility of this... what's the use of an AOM structure that might contain basic errors? Assuming one of the following stages of the parser does do the full RM check (mine does it in phase 2 validation) then the question is: between the point of having generated an AOM, but before having done the full RM check, what useful thing could you do with the AOM structure? One obvious answer is: display it in some way... but why? Maybe there are reasons that make sense, I just can't see them yet.
> >
> > ```
>
> ```
> It would be useful to be able to display an AOM structure that is invalid with respect to the RM. For example, an archetype editing tool that validates against the RM during parsing would presumably be incapable of loading the archetype and would throw an incomprehensible parser error at the user. Not nice. What would be much better would be if the editor could display the AOM structure, and then highlight the RM validation errors in a way that made it easy for the user to find and correct them.
>
> ```
I am warming up to the idea;-)
Practical question: what ADL syntax addition should be made to indicate multiple-valued attributes? It's not a constraint, so it's not part of the 'matches {}' syntax. I guess something like:
> container_attr **is_multiple** matches {
> ...
> }
or
> container_attr **is_container** matches {
> ...
> }
Questions:
- is it required if there happens to be a cardinality constraint on the same attribute (which also gives away that it is a container)?
- having "container_attr **is_multiple** cardinality matches {2..*} matches {" seems clumsy
- if a compiler uses the RM even in the parser stage, does it ignore this flag, or report errors when the flag doesn't match the RM definition?
- presumably the flag would be obligatory on serialisation; then the first question applies also.
- thomas
---
## Post #40 by @Peter_Gummer1
Thomas Beale wrote:
> • is it required if there happens to be a cardinality constraint on the same attribute \(which also gives away that it is a container\)?
> • having "container\_attr is\_multiple cardinality matches \{2\.\.\*\} matches \{" seems clumsy
I'm sure this must have been discussed before but I've forgotten the answer \.\.\.
Is there some reason why cardinality can't be mandatory on container attributes?
\- Peter
---
## Post #41 by @system
It is not mandatory anymore since you don't need to put it when you don't redefine the cardinality. But you gave me an idea. Maybe we don't need to add a new keyword, but just reuse the "cardinality" (or other more descriptive keyword as "container") and just make the matches part optional:
- Multiple attribute with redefinition of cardinality: container_attr cardinality matches {2..*} matches {
- Multiple attribute without redefinition of cardinality: container_attr cardinality matches {
2012/1/11 Peter Gummer <[peter.gummer@oceaninformatics.com](mailto:peter.gummer@oceaninformatics.com)>
---
## Post #42 by @system
I like this idea\. It is very close to what is implemented in the java
ADL 1\.4 parser\. We just need to make cardinality keyword mandatory
again for container attributes in ADL\.
Back to one of Tom's questions, "if a compiler uses the RM even in the
parser stage, does it ignore this flag, or report errors when the flag
doesn't match the RM definition?"
I believe the parser should report such errors\. Silently ignoring
errors like this doesn't seem to be a good approach to me\.
/Rong
---
## Post #43 by @Heath_Frankel3
Tom,
I am going to raise the issue of choice and sequence again in this context. I still haven't seen an example on how groups and choice is going to be implementation in 1.5 but my initial thought was to use a keyword indicating sequence or choice rather than cardinality. However the following suggestion of mandatory cardinality without matches constraint could work ok for specifying sequence using the existing is_ordered attribute, but this does need a default of false when not otherwise specified, which is contrary to the new RM default approach used in other attribute.
Heath
---
## Post #44 by @Heath_Frankel3
Hi Rong,
Like most compilers which have multiple stages where parsing is only an early step, I think we need to separate the adl parsing from the RM validation. This would still allow an error to be raised but support other tools to intercept between the steps to do something like Peter's visual representation of RM validation errors and others desire to not have an underlying RM.
Heath
---
## Post #45 by @thomas.beale
because now in ADL/AOM 1\.5, archetypes only carry actual constraints
w\.r\.t\. the RM\. Cardinality is occasionally constrained, but not often\.
We just freed ourselves from useless cardinality non\-constraints all
over the place \- we don't want to go back to that\.\.\.\.
\- thomas
---
## Post #46 by @thomas.beale
the purist in me doesn't like it, but it's quite a smart practical
solution\. Let's ruminate a few days to see if we can get a better
solution or not; I'll put in whatever we have by then\.
\- thomas
---
## Post #47 by @thomas.beale
The current solution is on [this page](http://www.openehr.org/wiki/display/spec/Ordering+and+choice+in+archetypes+and+templates) - the 'group' keyword. I have specified an equivalent in the AOM. I have not implemented it yet in the compiler.
- thomas
---
## Post #48 by @thomas.beale
I have seen no further response here, and my own background cogitations
did not come up with anything better \- if we are going to go for non\-RM
parsing, David's solution is cleaner than anything else I can think of\.
Does anyone want to comment further?
If not, I will create a specification CR on Jira and add this to the
main ADL / AOM 1\.5 spec\. As always, any substantive change to the specs
always gets credited to the author of the idea, and that is what appears
in the Revision history of the document\. David \- I am putting you down
as the author of this change \(in Jira and in the spec\)\. Let me know if
anyone else should be credited\.
\- thomas
---
**Canonical:** https://discourse.openehr.org/t/aom-1-5-single-v-multiple-attributes/15110
**Original content:** https://discourse.openehr.org/t/aom-1-5-single-v-multiple-attributes/15110