Hi Georg, Please note that you can always define your FROM clause with a high level node such as an OBSERVATION o[archetype_id] and access the particular path you're interested in using a path starting from o as in o/data[..]/...
Regarding your assumptions re FROM clause, technically there is nothing stopping you from writing a query such as SELECT x FROM EHR e CONTAINS DV_CODED_TEXT x. As useless as it may be, this is valid AQL and it asks for all the DV_CODED_TEXT instances in all compositions under all EHRs However, it is likely that most AQL implementations won't let you run this query simply because implementers don't want to pay the multi-dimensional price for supporting a theoretically possible but useless-in-real-life use-case. I'm telling this only because your comments sounds like you're assuming archetype node ids are mandatory in the FROM clause. They're not, from a syntax standpoint and maybe we should close that gap in the specs. So use the SELECT clause to define a path from the Observation and the aql implementation should give you the element you're interested in based on its archetype node id. Whatever serialisation format the back end uses (json/xml), you should always get an attribute or a json field telling you the actual instance type of DATA_VALUE, which you can use to process data. It is really no different than any subtype based polymorphism implementation where you're given a base (sometimes abstract) type and you need to figure out the actual type during runtime. All the best. S. On Mon, Apr 29, 2019 at 11:46 PM Georg Fette <georg.fe...@uni-wuerzburg.de> wrote: > Hello, > How do I constrain the Analyte result of a laboratory_test_analyte.v1 ? > The Analyte result are defined as an ELEMENT that is only constrained by > a node predicate (i.e. ELEMENT[at0001]). Therefore the results cannot be > bound with a specialized type and an alias within the FROM part, as in > the FROM part only archetypeID-predicates are allowed and no node > predicates. As the result is defined with the abstract ELEMENT type, > which has an abstract DATA_VALUE as its content, no paths can be defined > that constrain specific aspects of subclasses of DATA_VALUE that are > actually stored in the ELEMENT[at0001] field of the test_analyte. > How can this problem be resolved ? > 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
