Hi Ian, > I had not appreciated that the various flavours or Template are > published in the Java implementation. I suggest that we use this as > the source of truth. > > https://github.com/openEHR/java-libs/tree/master/oet-parser/src/main/xsd >
I am sorry to say that this is not possible, they are also outdated, but less then the link I got this morning. But "source of truth" sounds formal. I think the suggestion is very suddenly for such a formal decision. > emplate.xsd - .opt format > > https://github.com/openEHR/java-libs/blob/master/oet-parser/src/main/xsd/Template.xsd The match between practice and definition is quite good, but also needs some revision, I validated some OPT-files with the template.xsd by using Saxon EE. It came to reoccurring errors, which are only a few errors, but reoccurring and then it become many. And, to take in regard, XML-Schema is not the easiest way of defining a formal standard, you see some unnecessary restrictions. For example, many errors come from the use of "xs:sequence" in the definitions, while "xs:choice" is what is wanted. "xs:sequence" forces a defined sequence in an instance, and that is not what is wanted, as we can see on the results on CKM. Thereby, I think the OPT-definition is not good enough for production-use. I explained in my message to Sebastian. It has a lot of unnecessary overhead, and when dealing in a busy environment you should maybe want to reduce that. This illustrates some moving targets. > This is the technical artefact that most Template-supporting systems > e.g OceanEHR, Marand Think!EHR, Cabolabs, Code 24 etc use. I don't know how these organizations handle the missing formal definitions. Do they wait for formal definitions and in the meantime handle which seems wise to their programmers? They don't tell us of course, it is commercial interest to follow formal definitions which do not change. But also it is important that they need to deliver stable software now, and there is some friction between the two. And they need to make long term decisions on which customers can rely. > In practice this means that if I create a .opt , I can upload this to > one of these systems and it will be ready to use, with no need to > upload or manage the individual archetypes. Ah, now I understand, an OPT is in fact an archetype. The system does not need to know the underlying archetypes, is your argument, because the template has all of the information. But still I don't see why the OET & OPT artefacts exist. The OPT, designed better, more efficient, and convenient for programmers would do on its own. I also see another problem. How can a system be sure if a template complies with an archetype if it does not have that archetype? But Thanks a lot, Ian and Sebastian, You explained a lot, and helped me making some decisions. Bert On 22-10-14 13:10, Ian McNicoll wrote: > Thanks Sebastian, > > I had not appreciated that the various flavours or Template are > published in the Java implementation. I suggest that we use this as > the source of truth. > > https://github.com/openEHR/java-libs/tree/master/oet-parser/src/main/xsd > > CompositionTemplate.xsd - .oet format > > https://github.com/openEHR/java-libs/blob/master/oet-parser/src/main/xsd/CompositionTemplate.xsd > > This is the native format that Template Designer uses internally . It > is a diff i.e. it carries only the constraints on the underlying > archetypes, not any of the archetype info itself. This isa only ever > used as a design artefact. > > Template.xsd - .opt format > > https://github.com/openEHR/java-libs/blob/master/oet-parser/src/main/xsd/Template.xsd > > This is the technical artefact that most Template-supporting systems > e.g OceanEHR, Marand Think!EHR, Cabolabs, Code 24 etc use. . It is is > essentially a wrapper round the existing AOM schema, to support > aggregation and further constrinty of the archetypes. It is > essentially a 'compiled and flattened form which fuses the diff > constraints of the .oet with the underlying archetypes. In that sense > it is just a giant archetype, which internally is 90% compatible with > the AOM (and imports the same AOM schema). > > In practice this means that if I create a .opt , I can upload this to > one of these systems and it will be ready to use, with no need to > upload or manage the individual archetypes. > > .opt is also used to generate other downstream artefacts such as GUI > frameworks and code-stub libraries. The other schema that is generated > is Template DataSchema > > In ADL 2.0 terms, the .oet will be replaced by differential ADL, but > the .opt will remain as a final 'compiled' version of the template for > technical use. > > As part of the tooling re-development we should set up a wiki page to > document the various favours of template and template-related schema. > > Ian > > Ian > > > > On 22 October 2014 11:29, Ian McNicoll > <ian.mcnicoll at oceaninformatics.com > <mailto:ian.mcnicoll at oceaninformatics.com>> wrote: > > Hi Bert, > > You are correct - this is not the schema for .oet but an old very > first draft of a template schema which to my knowledge has never > been used and should probably be withdrawn. > > The schema for the operational template 1.4 .opt format is > available and I think that should be uploaded in its place. > > I am not sure that a schema for the .oet format exists. > > .opt is the key format > > Ian > > > > > On 22 October 2014 10:13, Bert Verhees <bert.verhees at rosa.nl > <mailto:bert.verhees at rosa.nl>> wrote: > > On 22-10-14 10:34, Thomas Beale wrote: >> >> Hi Bert, >> >> this page >> >> <http://htmlpreview.github.io/?https://github.com/openEHR/specifications/Release-1.0.2/publishing/its/XML-schema/index.html>should >> help it's the 'XML schema' link from the specifications page >> <http://www.openehr.org/programs/specification/releases/1.0.2>, >> near the bottom. > > Hi Thomas, thank you very much. > > I found this link already: > > https://raw.githubusercontent.com/openEHR/specifications/Release-1.0.2/publishing/its/XML-schema/Template.xsd > > But I don't know how to understand this schema in context with > OET-files I found on CKM. > > In those OET-files are elements like definition, > integrity-checks, rules, item, items, and much more. > It seems not to fit on the contents of this XSD which does not > define those elements. > > Do I misunderstand something? > > Bert > > >> >> - thomas >> >> On 22/10/2014 09:02, Bert Verhees wrote: >>> Hi, >>> >>> I must have been overlooking it all the time, but I cannot >>> find the formal definition of the OET-XML >>> Thanks for helping me out. >>> >>> Bert >>> >>> _______________________________________________ >>> 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 > > > > > -- > Dr Ian McNicoll > office +44 (0)1536 414 994 <tel:%2B44%20%280%291536%20414%20994> > fax +44 (0)1536 516317 <tel:%2B44%20%280%291536%20516317> > mobile +44 (0)775 209 7859 <tel:%2B44%20%280%29775%20209%207859> > skype ianmcnicoll > ian.mcnicoll at oceaninformatics.com > <mailto:ian.mcnicoll at oceaninformatics.com> > > Clinical Modelling Consultant, Ocean Informatics, UK > Director openEHR Foundation www.openehr.org/knowledge > <http://www.openehr.org/knowledge> > Honorary Senior Research Associate, CHIME, UCL > SCIMP Working Group, NHS Scotland > BCS Primary Health Care www.phcsg.org <http://www.phcsg.org> > > > > > -- > Dr Ian McNicoll > office +44 (0)1536 414 994 > fax +44 (0)1536 516317 > mobile +44 (0)775 209 7859 > skype ianmcnicoll > ian.mcnicoll at oceaninformatics.com > <mailto:ian.mcnicoll at oceaninformatics.com> > > Clinical Modelling Consultant, Ocean Informatics, UK > Director openEHR Foundation www.openehr.org/knowledge > <http://www.openehr.org/knowledge> > Honorary Senior Research Associate, CHIME, UCL > SCIMP Working Group, NHS Scotland > BCS Primary Health Care www.phcsg.org <http://www.phcsg.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/20141022/e5ef613b/attachment-0001.html>
