Hi Tom,
See comments inline please.

On Thu, May 2, 2019 at 12:52 PM Thomas Beale <thomas.be...@openehr.org>
wrote:

> Ian,
>
> If you were referring to the discussion about paths and data types, i.e.
> how do you know if you can refer to some path inside a DvQuantity if the
> archetype only knows about DataValue and LOINC codes, it's true that you
> can use such a path, if the real data (Element.value) happen to be a
> DvQuantity, but you have to be able to reliably figure this out at runtime,
> presumably by inferring it from the LOINC or other code - every time? In
> this situation the AQL processor cannot help you, because it doesn't have
> any information about what lies beyond the Element.value point in the
> structure.
>
As I mentioned in my response earlier, the serialisation of Element.value
would have either xsi:type (xml) or "_type" (json) letting the consumer of
the query process this information during runtime. You're right about the
aql processor not having much capability here, though this particular case
is not necessarily problematic since you'll have the archetype node id and
all data instances with that arch. nd. id will be of the same type. A
situation in which you'd need the aql processor to be smarter, but it
cannot be is if you used this Element.value with an operator that is valid
for particular types, such as '<'. So if you were to attempt to filter the
data with aql and used Element.value to filter say based on dates such as:

"...WHERE c/bla/../item[at0022]/value/value < '2008-02-03'"

this would require the AQL processor to do what you said, i.e. check actual
data type at runtime to make sure that Element.value is of type to which
comparison operator can be applied. Heath and I just discussed this issue
based on a feedback/question we received. I am currently in favour of
allowing a cast at the aql level via use of a CAST function, as various SQL
variants do. After all, based on the model the author of the query knows
that the path will contain a date. Read on for why I would not do what
you're suggesting

> It seems to me that it would be preferable to convert data with DataValue
> specific archetypes, since the general case is that data are written once,
> read many times. In that case, you will have data that always has a typed
> analyte Cluster archetype (e.g. to DvQuantity, DvOrdinal etc), and and the
> AQL service will be able to do proper type / path checking. AQL authoring
> tools will also be able to work in a more obvious way (e.g. with
> auto-complete on paths etc).
>
> So far I am not seeing a downside to this. I realise others have thought
> about it longer than I however ...
>
The downside is us, techies pushing our concern into modelling space. Very
much in the spirit of python seeing huge adoption over say Scala or Haskell
or even Java amongst scientists, I'd try to give clinical modellers some
space here. They would have to have a grasp of the type system arguments
above to see the justification for the (modelling) specialisation approach,
which I think is a weak argument here. My preferred compromise is to let
Aql engines know what to expect in advance using CAST (as a function, not
as a keyword) and let clinical modellers go on as things are a.t.m.

All the best
Seref

- thomas
> On 02/05/2019 12:02, Ian McNicoll wrote:
>
> The replies that seref and I gave address the issue. The vast majority of
> lab imports will use the generic analyte cluster.
>
> On Thu, 2 May 2019, 12:01 Ian McNicoll, <ian.mcnic...@gmail.com> wrote:
>
>> Thomas this is not a problem. The aql works as designed
>>
>
> _______________________________________________
> 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

Reply via email to