The rules package has some clear classes, which purpose is very clear, also most of the new classes are easy to understand, because of the previous version of the OAM which had the same classes, or recognizable constructs.
But some classes are really hard to understand. For example, ExprConstant is easy, but ExprConstant with CString, how does this differ from ExprConstraint?
It would be easy if classes in the AOM were recognizable in the grammar, I think the Grammar-rules can be mapped one to one to the classes, and it would be good for the understanding of the sourcecode if this would be done.
I don't know if there are some problems with this idea, maybe it can be done, partly.
Another example of hard mapping is adl_path in the grammar, is that the target_path in the AOM?
I think so, but I am not sure, and that feels uncomfortable.
I cannot find where it is explained. Maybe I missed it.
There is discussion possible if the grammar is implementation of definition.
Before this discussion starts, please allow me to give my point of view.
If it is implementation, then there is no explanation necessary, developers can decide how they want to map the AOM on the grammar as long as it stays inside the ADL-specs. And in the ADL specs there is no such thing as CCOMPLEX_OBJECT_PROXY, or even C_COMPLEX_OBJECT.
I don't think it is desirable to have a situation in which developers create an own mapping from grammar to AOM, the AOM can stay the same, but a complete other grammar is possible to implement the AOM. This kind of incompatibility does not seem wise to me.
So when seen from this point of view, the grammar should be a part of the definition/specs, and in that case, a good explained mapping between AOM and grammar is necessary.
The main incompatibilities, that need to be addressed, are in the rules package. I'm not sure what you mean about C_COMPLEX_OBJECT_PROXY and C_COMPLEX_OBJECT - they are in the grammar and in the AOM.
Agree in general that differences are not preferable. My suggestion is that we identify all differences outside the rules area, and I'll fix them first because they will be easier. There is still some design to finalise in the rules area.
I did not explain myself well, excuse me. There are differences in names in the grammar and AOM, this is understandable, because sometimes an attribute has another name.
For example, the grammar-rule adl_path can stand for an attribute called adl_path, but it can also stand for an attribute target_path, depending on the class/rule in which it is used, and mostly I find my way, but sometimes it takes quite some time, and I am not sure if I am doing the right thing. I must admit that I am not always equal smart.
Especially I find this a problem in the rules-package, because there are a series of new classes from which I do not understand the purpose very well. I don't have the code at hand, right now. Most of the new classes I did not implement in the definition-parser, because I felt unsure about how to use them, so from Strings I created a ExprConstant, that is good anyway, but what is the purpose of the ExprConstraint, or ExprArchetypeConstraint or ExprModelRef, I have hard times recognizing when to use them, especially in code, I find this difficult.
I have the idea that the grammar does not have a logical unambiguously path to a specific class, but that it is the parser on smart developer action has to decide when to use what.
Maybe I am missing something?
What could possibly help is ADL-examples where the new classes come to life.
We have separated out the rules package out in a new specification, which is a draft for now. See http://www.openehr.org/releases/BASE/latest/docs/rules/rules.html
This will be 'included' by AOM2 / ADL2. The exact changes for all this are not finalised. I recommend not to implement the rules part for now, until it has more discussion (which I think you need to be involved in).
I study the link this week, and come back to this