PPPS: How you define an AQL filter over a domain type?
2013/4/25 Diego Bosc? <yampeku at gmail.com>:
> As you know, I'm not a big fan of domain types, so take my comments
> with a grain of salt ;)
> I understand that back in the day when archetypes were hand crafted
> domain types could serve a purpose. But in my opinion ADL should not
> be written by hand nowadays. Tools should be the ones that 'hide' the
> 'verboseness' and provide the user with a simple interface to simulate
> domain types if you want/need that. Also, the difference in file size
> is negligible (if archetypes pass from 16kb to 20kb I wouldn't worry
> that much...).
> If you ask me I would get rid of them completely and make ADL
> completely model agnostic.
>
> This is why I can agree with the second point completely: There you
> are making ADL better, more powerful.
> But I see a problem with the first point as it still requires an
> external definition of the 'mappings' between how we understand codes
> in each one of the standards (and which information we can constraint
> about them). With this new syntax, can we constraint mappings between
> codes? ( How do I say that I don't want to allow the mappings in
> certain coded text?) and what about the code qualifiers? What if your
> RM defines another kind of attribute for codes interesting to be put
> into the archetypes but not supported by this code syntax?
> If both visions (codes as a type and codes as a full structure)
> coexist then we have the same problem as we have now (or worse).
>
>
> PS: BTW, by definition a leaf constraint type (the new proposed
> 'C_TERMINOLOGY_CODE' or whatever) does not have node id, I don't see
> how one would be able to define alternatives of codes from different
> terminologies or specialize that...
> PPS: ...which is the exact same problem that domain types have (as
> they also lack node id)
>
>
>
> 2013/4/24 Thomas Beale <thomas.beale at oceaninformatics.com>:
>>
>> In openEHR we use custom syntax in archetypes to express ordinal
>> constraints, quantity constraints and coded text constraints - i..e
>> constraints on what are probably the most ubiquitous data types in health.
>>
>> I have been mulling over feedback from previous debates here and in CIMI
>> about the 'undesirability' of this syntax.
>>
>> I have posted some new ideas on how to solve this here.
>>
>> The executive summary is:
>>
>> let's treat 'code' as a built in type, like a Date or a Uri; this then makes
>> an AOM type that constrains this trivial;
>> ADL can be augmented in a generic way to enable tuples to be constrained,
>> which would better solve the Quantity constraint problem
>> The Ordinal constraint syntax would be replaced by a combination of both of
>> the above.
>>
>> Feedback welcome.
>>
>> - thomas
>>
>>
>> _______________________________________________
>> openEHR-technical mailing list
>> openEHR-technical at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
