Hi Heath, As long as it is about data, I have no objection to richer semantics via additions to formalism. I've tried to avoid making comments about GUI directives in openEHR specifications in the past, but now that you have mentioned it, I consider those to be at least as evil as inheritence in XML (here we go...)
I'd like to see archetypes being about domain data. Just because the formalism is powerful enough to express something, should not mean that we include it in the model for convenience. It may work in some cases, but ADL is supposed to be consumed in so many contexts, in so many technologies. You should never open way to certain things in your design, because if is a well known design error, the size does not matter. People will abuse it, and it'll become a problem which will stick, due to backward compatibility. I know you know all of these, but I am writing this down, due to seeing repeating discussions about pushing aspects of other layers into ADL. Any software design book/course/seminar will tell everyone that it is bad to have gui related stuff in your business logic. We go to great distances to separate layers of software, introduce huge frameworks just for this, and then we forget why we've done that and go back to discussions about having GUI and behaviour in models. It is wrong, and I think it is reaching a frequency that requires some reminding about the bitter experiences of the past. Kind regards Seref On Wed, Mar 23, 2011 at 1:20 AM, Heath Frankel <heath.frankel at oceaninformatics.com> wrote: > Hi Seref, > I agree with you sediments regarding Archetypes. ?However, the AOM still > needs to support something like this for templates, in my view this is the > level where we will want to start making conditional statements about data > constraints (and this is still before we get to the GUI, as I may have the > same conditional constraint requirement in an integration scenario). > > Heath > >> -----Original Message----- >> From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- >> bounces at openehr.org] On Behalf Of Seref Arikan >> Sent: Wednesday, 23 March 2011 10:03 AM >> To: For openEHR technical discussions >> Subject: Re: future ADL-versions >> >> Greetings, >> I have a single question about this particular requirement/idea: why? >> >> Archetypes are model artefacts. That is it. They are supposed to >> describe domain models in a certain way. Behaviour or software that >> uses those models is a completely different thing. I can understand a >> constraint which references another one for defining a valid interval >> etc, but how on earth something like forcing a user for another entry >> is going to be handled during implementation? How would one express >> this in common formalisms like XML? >> >> I could understand a suggestion to use ADL to express rules regarding >> the archetypes, but that should be a formalism leaving in a separate >> space, which may be linked to archetypes, which >> only-contain-constraints-on-RM-types. >> >> Please keep behaviour our of models in ADL specifications. >> >> Regards >> Seref >> >> >> On Fri, Mar 18, 2011 at 8:10 PM, Bert Verhees <bert.verhees at rosa.nl> >> wrote: >> > Thanks, Thomas, for your reply. There is more to it then I initially >> > thought of. >> > >> > I am not very familiar with XPath. Best is to wait for more >> information >> > on the specs. >> > This is enough for now, to let customers give something to think >> about. >> > >> > Bert >> > >> > On 16-03-11 19:32, Thomas Beale wrote: >> >> >> >> Hi Bert, >> >> >> >> I hope to get back on the spec in the next couple of weeks. With >> respect >> >> to your specific question below, can you be a bit more precise? >> There >> >> are ways to express this kind of thing, but we need to be clear on >> >> distinguishing references to: >> >> >> >> ? ? * elements in the same archetype - as in a rule like: >> >> ? ? ? ? ? o /path/to/systolic/pressure/value > >> >> ? ? ? ? ? ? /path/to/diastolic/pressure/value >> >> ? ? * elements in data elsewhere in the same EHR like: >> >> ? ? ? ? ? o $date_of_birth:ISO8601_DATE ::= query(?ehr?, >> ?date_of_birth?) >> >> ? ? ? ? ? o this is still being finalised, so don't depend on it; >> >> ? ? ? ? ? ? however it is the left hand side that matters, i.e. >> >> ? ? ? ? ? ? $date_of_birth >> >> ? ? * environmental values, like >> >> ? ? ? ? ? o $current_date >> >> ? ? ? ? ? o $current_time >> >> >> >> Some of this is still being finalised, but the general syntax will >> look >> >> like Xpath and the object model will be what you would expect from >> that. >> >> >> >> - thomas >> >> >> >> On 10/03/2011 15:48, Bert Verhees wrote: >> >>> Hi, >> >>> >> >>> I am sorry, but I am to busy to read all the discussions on future >> >>> ADL-versions. >> >>> So, now I have a small question, which possible is already >> explained, >> >>> >> >>> Is it possible to write conditional constraints in future ADL? >> >>> >> >>> The question is about implementing care-protocol into an archetype. >> >>> >> >>> For example, if blood-pressure is> ?200, force to use another >> entry, for >> >>> example also look at heartbeat >> >>> >> >>> Is there any idea when this new specifications will be in final >> version? >> >>> >> >>> Thanks >> >>> Bert >> >>> >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> openEHR-technical mailing list >> >>> openEHR-technical at openehr.org >> >>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> >>> >> >> * >> >> * >> >> >> >> >> >> >> >> _______________________________________________ >> >> openEHR-technical mailing list >> >> openEHR-technical at openehr.org >> >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> > >> > _______________________________________________ >> > openEHR-technical mailing list >> > openEHR-technical at openehr.org >> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> > >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >
