As things stand, No, the spec does not allow such a thing (since it is
unspecified at the moment) and also partially No, (I don't think) it should
not allow such a thing auto-magically or try to be smart about it.

As things stand, AQL has only access to information provided by the RM. I
for one would be uncomfortable with Aql queries making assumptions about
actual subtypes of abstract/parent types because validating those at the
query level is impossible.
It is semantically 'downcasting' the type and it should only be done in an
explicit way when the authors of the queries explicitly declare the cast
and take the risk.

I'll take a look at the example you mentioned, but it does not sound right
to me. My earlier response to Tom mentioning comparison operators also fall
under this topic.

All the best

On Fri, May 3, 2019 at 12:10 PM Georg Fette <>

> Hello,
> I have a question the is a bit related to the discussion about the
> constraining of the ELEMENT type in the laboratory_analytes.
> The current specification defines the field "ehr_status" of the class
> EHR with the type OBJECT_REF. In the AQL specification there is an
> example (chapter NOT) that accesses this field with the
> assumption that the field is of type EHR_STATUS.
> I have written a type checker for AQL queries, so I am now stumbling
> across queries that access fields of potential subclasses or derived
> archetypes.
> Does/should the specification generally allow such a thing ?
> Greetings
> Georg
> --
> ---------------------------------------------------------------------
> Dipl.-Inf. Georg Fette      Raum: B001
> Universität Würzburg        Tel.: +49-(0)931-31-85516
> Am Hubland                  Fax.: +49-(0)931-31-86732
> 97074 Würzburg              mail:
> ---------------------------------------------------------------------
> _______________________________________________
> openEHR-technical mailing list
openEHR-technical mailing list

Reply via email to