Bah, meant "..(I think) it should not..." On Fri, May 3, 2019 at 12:19 PM Seref Arikan < serefari...@kurumsalteknoloji.com> 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 <georg.fe...@uni-wuerzburg.de> > 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 3.7.2.3. 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: georg.fe...@uni-wuerzburg.de >> --------------------------------------------------------------------- >> >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical@lists.openehr.org >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
