shortened matching types in cADL

Implementers (archive)
1

From the spec 4.4

While constraints on complex types follow the rules
described so far, constraints on attributes of
primitive types in cADL can be expressed
without type names, and omitting one level of braces, as

follows:
some_attr matches {some_pattern}

rather than:
some_attr matches {
  BASIC_TYPE matches {
    some_pattern
  }
}

2

Andrew Patterson wrote:

>From the spec 4.4
While constraints on complex types follow the rules
described so far, constraints on attributes of
primitive types in cADL can be expressed
without type names, and omitting one level of braces, as

follows:
some_attr matches {some_pattern}

rather than:
some_attr matches {
  BASIC_TYPE matches {
    some_pattern
  }
}
--------

However, I can't see how in the grammar the non
shortened form could ever work. i.e.

if we changed the shortened form from:

ELEMENT[at0010] matches { -- diastolic blood pressure
  value matches {
    QUANTITY matches {
      magnitude matches {|0..1000|}
    }
  }
}

to

ELEMENT[at0010] matches { -- diastolic blood pressure
  value matches {
    QUANTITY matches {
      magnitude matches
        DV_INTERVAL matches {|0..1000|}
    }
  }
}
  

actually, it can't be DV_INTERVAL, because that is not a basic type; it
would be Interval<Integer> - these types are the primitive types assumed
by openEHR, based on ISO 11404 (see Support IM -
http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/rm/support_im.pdf)

Things can seem confusing sometimes with the DV_ types and primnitive
types, because there are similarities. But the DV_ types are complex
(albeit low-level) types that all inherit from DATA_VALUE, an openEHR
type, and can therefore be used as values for ELEMENT.value. The
primitive types are whatever you hav available in your programming
language or other formalism, such as XML. Some formalisms are stronger
than others, e.g. some won't have an idea of Interval<T: Comparable>,
which is why we explicitly say what openEHR's assumed model of it is.

Also, in practice, I don't think anyone has yet wanted to use the
expanded form of primitive types you quoted above anyway. We did it for
a particular reason: it allows the values to be parsed to whatever is
most natural in an environment (Java, C#, XML etc) without forcing type
names on everybody (Integer, int, String, String_32, ...Date, DateTime,
Calendar....) - so it makes ADL texts more usable over more
implementation environments (we hope;-)

hope this helps,

- thomas

3

Also, in practice, I don't think anyone has yet wanted to use the
expanded form of primitive types you quoted above anyway. We did it for
a particular reason: it allows the values to be parsed to whatever is
most natural in an environment (Java, C#, XML etc) without forcing type
names on everybody (Integer, int, String, String_32, ...Date, DateTime,
Calendar....) - so it makes ADL texts more usable over more
implementation environments (we hope;-)

ok - I just guessed at DV_INTERVAL.. my point was that the grammar
in the document doesn't allow it (no matter what the type is
called). Which is fine by me - I agree that not forcing the type names
is a good idea - but that means the text of the ADL doc shouldn't
mention the expanded form at all (unless to mention that its not
supported)

Andrew

4

Andrew Patterson wrote:

Also, in practice, I don't think anyone has yet wanted to use the
expanded form of primitive types you quoted above anyway. We did it for
a particular reason: it allows the values to be parsed to whatever is
most natural in an environment (Java, C#, XML etc) without forcing type
names on everybody (Integer, int, String, String_32, ...Date, DateTime,
Calendar....) - so it makes ADL texts more usable over more
implementation environments (we hope;-)
    
ok - I just guessed at DV_INTERVAL.. my point was that the grammar
in the document doesn't allow it (no matter what the type is
called). Which is fine by me - I agree that not forcing the type names
is a good idea - but that means the text of the ADL doc shouldn't
mention the expanded form at all (unless to mention that its not
supported)

yes, I have been tempted to take it out for a while, but then of course
some annoying person will find a really good reason for having it in.
And as you say the current grammar probably doesn't deal with it (you
can tell how unimportant it is - we;ve obviously never even though to
test it...)

- thomas