I’ve been thinking further about the rules question.
Let’s make the following assumptions:
rules are in a separate section of an archetype (and not spread through the main definition section)
why? This distinguishes cleanly ‘first order’ constraints (ADL) at a per-object level from n-th order constraints (rules) that operate across n variables
we use a style of bindings to establish ‘scopes’, in the same way we would understand it in programming, rather than every variable being bound to an absolute path.
why? This has the equivalent effect of rules being stated within the relevant {} ADL sections, without literally having to do that. It also makes the execution engine easier to implement, since it doesn’t have to infer much.
I would therefore propose the following way of doing rules, as per this example:
In the above, the expression evt/apgar_total_value is shorthand for evt.child(apgar_total_value), i.e. an Xpath-like expression that gets a child at a certain path.
If we were to agree on this, the next question is in what version do we add it? Possibilities:
I think we leave it out of Release 2.2.0, which otherwise has additions that are mostly implemented or being implemented in tools.
We define the next release of ADL 2.5, and add it there.
We define a 3.0 release and add it there.
I would propose we put it in a release called ADL 2.5, because we are not proposing to change ADL itself, i.e. ADL2 and AOM2 are still valid; the rules section just adds something.
If we agree on this, I will try to complete ADL 2.2 and ADL 2.3 in a form that doesn’t update the rules section syntax (the meta-model will change to the newer EL meta-model, because the old EL meta-model is now some years out of date and no longer maintained).