Hi Pablo, What issues do you have with the XSD? We have been producing valid instances for years. I have tools that can validate these in seconds. I am sitting on hundreds of test instances. Problem is I am not sitting around with nothing to do. If you have a student willing to do some dot NET code with little support you can go to openehr.codeplex.com to get what you need to create and validate openehr instances against OPTs and RM.
BTW, I have a local xsd that further constrains the published schema that picks up several additional RM invariants. Happy to contribute this but don't want to confuse the status of the official schema. I also have a demographic schema which I believe is currently not part of the current openEHR release. Heath On 08/05/2012 12:09 AM, "pablo pazos" <pazospablo at hotmail.com> wrote: > Hi Seref, I've a tool that generates composition instances from > archetypes and data, what I don't have is a way to generate a valid XML > form from those compositions. > > In order to do that, we should resolve current reported issues with the > XSDs (see my first email), and then generate XMLs, at first maybe by hand, > later integrated into tools. > > -- > Kind regards, > Ing. Pablo Pazos Guti?rrez > LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez > Blog: http://informatica-medica.blogspot.com/ > Twitter: http://twitter.com/ppazos <http://twitter.com/ppazos> > > ------------------------------ > Date: Mon, 7 May 2012 15:26:28 +0100 > Subject: Re: How about creating an openEHR test base? > From: serefarikan at kurumsalteknoloji.com > To: openehr-technical at lists.openehr.org > > I don't have the time to do what I'm going to suggest next, but if someone > has time in their hands, I'd suggest writing a tool that will automatically > generate valid XML RM documents, such as compositions etc. > > Archetypes and templates define boundaries of all valid instances of > clinical models, and one can generate random instances that belong to this > set. Opereffa's current version supports this, but not with XML output. I > used this approach to test performance of persistence options > > If our argument is that all the clinical information can be represented > via models, why should be create RM instances by hand? > > Regards > Seref > > > On Mon, May 7, 2012 at 3:05 PM, pablo pazos <pazospablo at hotmail.com>wrote: > > 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.beale at 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 > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120508/181377e5/attachment-0001.html>
