Hi Thomas, just to be sure we are on the same page:
>From previous emails:
What we need is to test our implementations (EHRs, services, repositories,
etc), we don't want to test the tools or the specs (i.e. we will not use an
archetype for a "guitar" concept).
We want to concentrate on flat archetypes and operative templates, things that
will be used by systems, not on source ADL archetypes with slots, abstract
types and other things that makes implementation a pain in the 4$$... you know
what I mean.
JSON and other serialization formats should be considered only for transport
purposes, not for modelling, BTW I mentioned only RM instances in JSON, not
archetype instances (but it's possible to transport archetype and templates
using JSON).
What I want (and maybe others) is:
1. to be sure that RM XSDs are correct compared to the specs,2. have some RM
XML instances are correct validated against XSDs,3. to have RM XML instances
generated for some OTPs, with the referenced source archetypes and term sets
accessible too,4. create some JSON form of those RM XML instances to play
around with REST services and web browser/javascript apps,5. create some test
cases in our own projects to be sure we are ok, maybe share those tests and
results,6. maybe do some interoperability tests, e.g. generate some of this
artifacts in one system, transport them to another and see if test cases pass
or not.
What do you think guys?
Kind regards,Pablo.
Date: Mon, 7 May 2012 10:30:34 +0100
From: thomas.be...@oceaninformatics.com
To: openehr-technical at lists.openehr.org
Subject: Re: How about creating an openEHR test base?
On 06/05/2012 13:28, pablo pazos wrote:
Hi Peter, thanks for the pointer.
I think this is only ADL related and only 1.5. My idea is
to include ADL1.4 and RM instances in XML and JSON, RM &
AOM XSD, also term sets.
Maybe we can took some samples from
there, but I believe this new repo has a wider scope. What do
you think?
My view is that this existing repository should be expanded to
include all test case archetypes in ADL and any of the other
serialised formalisms. Today it does mainly concentrate on ADL/AOM
1.5 test cases. Let's think about what other test case material
could be added, and how it should be organised. Rong Chen (Sweden)
and Koray Atalag (NZ) have thought quite a lot about this in the
past and I am sure would have ideas to contribute - Erik Sundvall
has been thinking about some of the other serialisations. I have to
admit to only having seriously thought about test cases for
bidirectional tool processing, which is currently ADL, dADL, and
will extend to XML-AOM (I just haven't gotten around to this yet).
I have not thought too much about test cases for JSON or YAML, but I
have done the output serialisations for them. Having done the first
implementation of JSON, I think it is too weak a formalism to be
seriously useful, because it lacks too many basic semantics -
particularly dynamic type markers. Its cousin YAML is
over-complicated (and in its whitespace form, nearly impossible to
get right!), but does have proper OO semantics and I think can be
used as a lossless serialisation. Others may have more evolved ideas
on how these particular formalisms should be used in openEHR, so I
am very happy to be educated by the experts. My main aim is to make
sure that the transformations of ADL => JSON and ADL => YAML
are correct. You can experiment with JSON, YAML and XML outputs of
any ADL 1.4 or 1.5 archetypes right now, using the ADL workbench,
which has a bulk export mode into these formalisms.
We have already discussed last week with Rong & Sebastian about
moving the openEHR terminology there, and how to manage it more
effectively, so the scope of this knowledge repository is going to
continue to grow anyway. So any community input on how to expand
this repository and manage it is welcome from my point of view (I
realise the above might only be a subset of your original scope
Pablo, so there are probably some things that still need to be done
elsewhere.)
- thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120507/80df2ed3/attachment.html>
