IMHO, archetypes need to be specifiable independent of the platform and language, including the querying. How archetypes are to be stored on disk should also not be part of the specification. Rather they should have a data model independent of platform and language. I assume that if archetypes are specified by XSL Schema then one would use a form of XPath to query them(?). I actually like something like the Object Constraint Language for this purpose, but this might not be popular.
We have used C++ for more than 15 years and find it not particularly easy to embed in other languages compared to other approaches. It should have nothing to do with the OpenEHR specification. Dave Forslund At 11:23 PM 3/24/2003 +0700, dhlong at vietkey.net wrote: >I thing C/C++ is the good choice, it's more popular, easy to embed in other >language, multi-platform. > >----- Original Message ----- >From: "Thomas Beale" <thomas at deepthought.com.au> >To: "Rafal Szczesniak" <mimir at diament.ists.pwr.wroc.pl> >Cc: <openehr-technical at openehr.org> >Sent: Monday, March 24, 2003 8:16 PM >Subject: Re: Introducing myself + question > > > > > > > > Rafal Szczesniak wrote: > > > > >On Sun, Mar 23, 2003 at 11:53:31PM +1000, Thomas Beale wrote: > > > > > > > > >>if you are thinking of specific querying language - I would agree - we > > >>can already see that the use of archetypes at runtime changes how > > >>queries are written and does require some new kind of language. We have > > >>been experimenting on this, and are working on it... > > >> > > >> > > > > > >Yes, I'm particularly interested in this and also in actual storage > > >techniques. As archetypes change and new ones are being added, the way > > >the data in files (it has to be stored somewhere, eventually) on disk > > >has to follow the changes. > > > > > This is the reason we aim to define a small, very stable reference model > > (ODP information viewpoint) - even if new archetypes are added, they > > just introduce new ways of combining existing kinds of bricks together, > > rather than new kinds of bricks. Information created according to an > > archetype which has a new version created (correcting an error) will > > have to be migrated, but not because the information building blocks are > > wrong - because some structure or content is no longer valid. We hope > > that this will not happen often. This is one of the reasons why > > archetypes and templates need to undergo quality assurance, both > > technically and clinically. > > > > Archetypes can also be created as specialisations of existing > > archetypes; these will not invalidate existing data. > > > > > Besides, no one of currently known query > > >languages is able to reflect complicated structures of health records. > > >At least I don't know of one. > > > > > the archetype path mechanism is one of the elements that will be used to > > make querying more powerful. Another is inspection of the "archetype > > maps" of data, providing a "data xray" without having to read the data. > > > > - thomas beale > > > > > > - > > If you have any questions about using this list, > > please send a message to d.lloyd at openehr.org > >- >If you have any questions about using this list, >please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
