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
