Diego Bosc? schreef op 6-2-2014 10:27: > I believe that for non leaf nodes I'm sure you can easily check for > check form occurrences and types, I don't remember if cardinality was > taken into account, I have to check that. For leaf nodes, I don't > remember having any trouble specifying that kind of constraints.
Thanks ;) Bert > > > 2014-02-06 Bert Verhees <bert.verhees at rosa.nl > <mailto:bert.verhees at rosa.nl>>: > > Diego Bosc? schreef op 6-2-2014 9:52: >> Regarding consistency checks, we have been able to generate >> schematron rules from the archetypes to check constraints stated >> on the archetype on the XML files. I think it is also what HL7 >> people uses for validating instances. > > Hi Diego, I am to using Schematron for validation-purpose, but I > use it together with RelaxNG, because RelaxNG is better in testing > structures and Schematron is better in validating simple constraints. > But creating a RelaxNG from an archetype is difficult, that is > complex and hard to maintain code. > > But now I see your message, I think it could be possible to create > Schematron only and check every possible constraint, which mostly > (not on leaf-nodes) are occurrences and cardinality. > > Do you have every possible constraint in an archetype covered by > Schematron? > > Bert > > > >> >> >> 2014-02-06 Birger Haarbrandt <birger.haarbrandt at plri.de >> <mailto:birger.haarbrandt at plri.de>>: >> >> Hi Ralph, >> >> > Am 05.02.2014 um 20:34 schrieb Ralph van Etten >> <ralph at medvision360.com <mailto:ralph at medvision360.com>>: >> > >> > On 02/04/14 17:33, Birger Haarbrandt wrote: >> > >> > Hi Birger, >> > >> >> Erik's approach >> >> was to develop a proprietary XML Schema to wrap >> compositions and >> >> contained entries. Obviously, this might work in a native >> XML database >> >> like eXist but does not serve our needs. >> > >> > Could you tell more about why a XML database does not serve >> your needs? >> > >> >> That is because we got both complex and simple data >> structures. For example, we got millions of equally >> structured demographic data and lab values that can perfectly >> be represented in a static data schema. Furthermore, there is >> lots of catalogue data that fits best into relational tables. >> (Another important reason is, that our abailable ETL an BI >> tools are optimized to work with SQL Server...) >> >> >> > >> >> Additionally, storing the >> >> archetypes in a relational fashion is not be our first choice. >> > >> > Why not? >> > >> >> We have to do the trade off between performance and >> understandability of the data model. Medical data can become >> very complex. As we need to build data marts from our >> database it's more important to understand the data as it's >> not a real-time system. In my opinion that's a lot easier >> when you have data structured in a hierarchical way as a >> document (what XML is perfect for). >> >> >> > >> >> Therefore, I'm interested to learn if any of you has >> already spent some >> >> thoughts about best practices to split compositions into >> individual XML >> >> documents while keeping the relationship throughout >> different tables >> >> and/or rows. >> > >> > I just released information about our "archetyped" >> MEDrecord. Our goal >> > was to create a more friendly API for MEDrecord based on >> archetypes. >> > While developing this API it proved to be a small step to >> also generate >> > SQL schemas from the archetype so that is what we tried. >> > Now we have a version of MEDrecord which stores data in a >> XML database >> > and a version which stores data in an SQL database whose >> schema is >> > generated using archetypes. >> > >> >> Are both versions available as open source? Yesterday I took >> a look at it (just the code) and was impressed by your work! >> >> > More information about the generated API and schemas can be >> found here: >> > >> > http://www.medrecord.nl/medrecord-json-api/ >> > >> > We are planning to implement some use cases and then see >> which approach >> > (XML database or SQL database) works best. >> > >> > But like I said, the main goal of the "archetyped" >> MEDrecord was to >> > provide a clean, type safe API to clients and not something >> which can >> > store anything without generating some code first. >> >> I'm wondering about it's capabilities to do validation of >> clinical data against archetypes. Is it possible to >> deserialize openEHR XML and check it for consistency or is it >> a one way ticket so far? >> >> > In time the "archetyped" MEDrecord might grow into such a >> solution, but >> > currently, for our use cases this is not important. >> > The important aspect is that we can create a clean API >> quickly which is >> > based on archetypes. >> > >> > What works best, relational database, native XML database or a >> > combination (like PostgreSQL with its XML datatype) is >> something we >> > still have to figure out. Although I see the benefits of >> using a native >> > XML database, I do not believe it will have decent >> performance any time >> > soon on cheap hard- and software for the type of queries we >> need for >> > building user interfaces without adding many more complexities. >> > >> >> I'm happy to exchange gained experience. I already got two >> ideas but I will need to do the implementation first. If it >> works I will create an article in the wiki. >> >> > Also, we basically treat archetypes as the schema for the >> information so >> > putting a schemaless database beneath it seems to be a bit of a >> > mismatch. Instead we attempt to convert the schema provided by >> > archetypes into a schema suitable for relational databases >> and I must >> > say I am quite pleased with the lack of complexity on the >> server side. >> > The server code turned out to be quite straight forward and >> simple. >> > Even the complexity of the generator which converts the >> schemas is >> > manageable. >> > Of course there is room for improvement and maybe it is not >> enough to >> > implement all possibilities of OpenEHR but for now it is >> enough to >> > implement the use cases we have in the foreseeable future. >> > We plan to develop it as new use cases present themselves >> instead of >> > trying to build something which can do anything first and >> then see if we >> > can fit the use cases in there. >> > >> >> I think your project might be a great starting point to >> implement a reference CRUD system people can learn from to >> build their own applications. Thank you very much for sharing :D >> >> > >> > Regards, >> > >> > Ralph van Etten >> > MEDvision360 >> > >> > >> >> Best, >> >> Birger >> >> >> > -- >> > This e-mail message is intended exclusively for the >> addressee(s). Please >> > inform us immediately if you are not the addressee. >> > >> > _______________________________________________ >> > openEHR-technical mailing list >> > openEHR-technical at lists.openehr.org >> <mailto:openEHR-technical at lists.openehr.org> >> > >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at lists.openehr.org >> <mailto:openEHR-technical at lists.openehr.org> >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> >> >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at lists.openehr.org <mailto:openEHR-technical at >> lists.openehr.org> >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > <mailto:openEHR-technical at lists.openehr.org> > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > > > _______________________________________________ > 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/20140206/a8e0fa00/attachment-0001.html>
