Bert Verhees wrote:
definition
AD[at0001] matches {
complexContent existence matches {1..1} cardinality matches
{1..1; unordered} matches{
BOOLEAN matches {
value matches {true, false}
}
}
}
Hi Thomas, please allow me another question, I know I always use a lot
of words, but maybe this long question is fully satisfied with a short
answer.
First, excuse me for using colours in this email, which messes up the
email for flat-text email-agents. It was necessary in this case for
readability
no need to apologise, I love colours...
I created the archetype you sketched above, and I run it, and printed
it toString()
I get following result (that is where I have a few questions about,
and what I did not understand) (it is from 0.95-version, I changed it
a bit for readability)
I can see some 0.95-isms that should be gone in the current version:
* the paths no longer include /[atnnnn]/ at the front, they always start
with /attr_name
* paths no longer ever have "." characters in them
I found the step I missed, insert another CComplexObject and call it
with rmTypeName=BOOLEAN. I never understood from the documentation
that a CComplexObject was also meant to reflect a type.
based on the idea that every "object" must have a type in an OO system...
I wonder, how does the parser know, is it because of the rmTypeName?
Not sure about the Java parser, but the Eiffel one does differentiate
between names that start in upper case (types) and names that start in
lower case (attributes). You can sill use whichever convention you like
e.g. like I do with SECTION/items or in the Java way Section/items. It
is stated early in the cADL section of the document. I am pretty sure
that the Java parser also does this check. I know it is something that
should not strictly be necessary, but since every programming language
today seems to use first-letter-upper-case for type/class names, and
first-letter-lower-case for attribute and function names, I think it is
a reasonable simplification for the parser-writers.
I could not find this in the documentation. But maybe I missed it.
I wonder, because words like BOOLEAN or TEXT are reserved words, it is
not possible to use these words for other purposes as rmTypeName. I
expected to find it in the ADL document, because one should know when
writing an ADL-file, I was thinking.
these are not reserved words in ADL - the only reserved words are things
like "cardinality" and so on. Note that we tend to drop the "Dv" from
the DV_ types (or "DvXxxx" types in Java/C#) to make the archetypes more
readable for everyone, and to make them more re-usable outside a strict
openEHR environment. So - where I used "BOOLEAN" before, it is shorthand
for DV_BOOLEAN (or DvBoolean;-) - which is the openEHR data type of that
name, not the built-in "boolean" of programming languages. The openEHR
DvBoolean has a boolean value, and also inherits from DATA_VALUE, making
it usable as an openEHR "data type", e.g. in Element.value (of type
DataValue). You never need to mention built-in type names like String,
Integer, Boolean etc, since they are inferred by the parser looking at
their values - these are the leaf values in ADL. This,
{123} is constraint on an integer (must = 123)
{|100..200|} is a constraint on integer (must be between 100 and 200)
{123.456} is a real / or float constraint
{true} is a boolean
{"something"} is a string
{/..*/} is a regex pattern constraining a string
so you never see the words "integer" or "string" or "boolean" anywhere.
The boolean / DvBoolean types can be confusing, and it is one of the
reasons why we have the "Dv" in openEHR.
hope this helps.
- thomas