This page makes two different proposals for improving ADL in a generic way, that would remove the 'custom syntax' used to efficiently represent constraints on Coded text, Quantity and Ordinals.
...
value matches {
QUANTITY matches {
property matches {“temperature”}
[units, magnitude] matches { -- this is not currently legal ADL
[{“deg F”}, {|32.0..212.0|}] ,
[{“deg C”}, {|0.0..100.0|}]
}
}
}
In the above, the {} surrounding each leaf level constraint are needed because although such constraints are typically atomic, as above, they may also take other standard ADL forms such as a list of strings, list of integers etc. In the latter case, the ',' characters from such lists will be conflated with the ',' separator of the distinct constraints in the tuple. Use of {} is also logically justified: each such entity is indeed a 'constraint' in the ADL sense, and all constraints are delimited by {}.
The above defines constraints on units and magnitude together, as tuples like [{“deg F”}, {|32.0..212.0|}] . It also removes the need for at-codes, since now we just have one object. This would work for tuples of 3 or more co-varying properties, and is mathematically clean. It would be some work for compilers to digest it, but... that's unavoidable.
If we look at the ORDINAL data type constraint in the same light. First, doing a typical ordinal constraint (a scale of +, ++, +++) with just standard ADL:
ordinal_attr matches {
ORDINAL [at0004] matches {
value matches {|0|}
symbol matches {
CODED_TEXT matches {
terminology_id matches {"local"}
code matches {"at0001"} -- +
}
}
}
ORDINAL [at0005] matches {
value matches {|1|}
symbol matches {
CODED_TEXT matches {
terminology_id matches {"local"}
code matches {"at0002"} -- ++
}
}
}
ORDINAL [at0006] matches {
value matches {|2|}
symbol matches {
CODED_TEXT matches {
terminology_id matches {"local"}
code matches {"at0003"} -- +++
}
}
}
}
Today, in ADL we use the more efficient syntax, which is not only smaller, but removes the need for the three at-codes above:
ordinal_attr matches {
0|[local::at0001], -- +
1|[local::at0002], -- ++
2|[local::at0003]; -- +++
0 -- assumed value
}
This hides the ORDINAL type altogether, and has the same advantages as the CODED_TEXT argument I described above. On the other hand, the above syntax is for Ordinals only, and requires something special in the AOM to support it. But we could also solve the problem using the tuple approach above:
ordinal_attr matches {
ORDINAL matches {
symbol, value matches {
{CODED_TEXT matches {code matches {"at0001"} terminology_id matches {"local"}}, 0} -- +
{CODED_TEXT matches {code matches {"at0002"} terminology_id matches {"local"}}, 1} -- ++
{CODED_TEXT matches {code matches {"at0003"} terminology_id matches {"local"}}, 2} -- +++
}
}
Now, this is still ugly, but if we adopted the idea of the coded term type as a primitive (like Date, etc), then we could do this:
ordinal_attr matches {
ORDINAL matches {
[symbol, value] matches {
[{[local::at0001]}, {0}], -- +
[{[local::at0002]}, {1}], -- ++
[{[local::at0003]}, {2}] -- +++
}
}
The above seems very clear, and relies only on the AOM supporting an 'inbuilt terminology code' data type, and tuple constraints, but any special RM type support can now be removed. This Tuple-based solution is more generic and would appear to solve more problems at once than the current custom syntax, which is dependent upon RM types. Coupled with an inbuilt primitive code type, it makes for very concise ADL structures.
Now, one question in all this, is: who cares about ADL, all we care about is the AOM. Notice that the Tuple-structured ADL clearly does imply a different kind of AOM structure, and that structure will then appear in other serialisations that you may want to use, including XML, JSON etc. So here I am really just using ADL for clarity of explanation, not definitionally (one of the main reasons we need abstract syntaxes like ADL in fact).