Bah, meant "..(I think) it should not..."

On Fri, May 3, 2019 at 12:19 PM Seref Arikan <> wrote:

> 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
> Seref
> On Fri, May 3, 2019 at 12:10 PM Georg Fette <>
> wrote:
>> 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