Thanks Sebastian and Ian, Ian, you are right, the XSD Thomas linked to is confusing and should have been withdrawn.
Indeed, for the OPT you can go to the AOM-XSD. In fact, an OPT is like an XML-archetype, nothing more. It has the option to include more archetype-Id's, in fact, a lot like slots but then with no wildcards. But it is not an archetype, it is a template. When you look at templates this way, it looks a lot like a slotted archetype, but in fact, the paths which can be deduced are in fact paths to external archetype's. That is not very convenient for programmer's. They have to walk through the chained elements to calculate/discover the paths where the data are. For that, the OET format is much more convenient. > You can generate the TDS which I think you are referring to from CKM > directly for any COMPOSITION template I looked at it, and I discovered it already before. But it is not what I am looking for. It creates an XSD for that specific template, where datafiles for that template should comply to. I am looking for an XSD which is a formal definition of the OET format itself. If I want to write OET-using software, I must be able to validate if a template to be used is according the rules. And that I cannot find. > CompositionTemplate.xsd is the main one I looked at the CompositionTemplate.xsd, it has a lot of elements the OET-files have, but I can see, since then, a lot has changed. But it gives some anchors for understanding. ;-) > OPT would be generated from OET+the archetypes. So essentially it is > combining archetypes and restricting them further > but which doesn't carry the whole information from the archetypes - > that would get you into a maintenance nightmare. I don't see that point. The information/constraints the archetype has, can be taken care of at design time, and easily checked afterwards for validity. For example, cardinality and occurrences/existence are easy to express in OET, without much extension in the definition of the OET-XSD. I see a lot of space used in the elements is used by the occurrences-definition. XML-Schema has the exact same mechanism as attributes which is less verbose. Cardinality should also use this mechanism, and then extended with two extra-attributes "ordered" and "unique" Same for archetype_id and node_id. Of course XML-parsers are very much optimized for validating on normal XSD-mechanism. Reading attributes cost less memory and less processor time then reading element-structures. And the parsed document is much smaller, so the used memory is smaller, and this allows for DOM-parsing instead of SAX-parsing. DOM-parsing has much more flexibility and speed, but it needs to take the whole document in memory I think the OPT is too faithfully a translation of the AOM, and that is why it becomes a nightmare. It is not optimized at all. And then we have the constraints on primitives. I think there are four kinds, list, interval, pattern and exact value. Maybe I forgot one. I don't see how these small items can change the OET-format into a nightmare. So this all would already clean up quit a bit of nightmare, without losing any information or expression. It can be that I overlook a lot things, and if, I am very eager to see what. I have the problem of a missing formal definition of the template-model, and now I learn that there is a risc of a nightmare, when I combine information which is handled separated. I wonder if that is true. I am now in a difficult situation for me, and I have to take some longterm development decisions regarding template-functionality, very soon. Should I follow and wait for the OpenEHR developments, or should I go my way? Thanks Bert On 22-10-14 12:28, Sebastian Garde wrote: > Hi Bert, > > My understanding only - but I'll give it a go to answer your questions > as good as I can. > > On 22.10.2014 11:52, Bert Verhees wrote: >> I have, in context of my previous question some more questions. >> >> Is it the case that there are no formal definitions for OET and for OPT? >> Is it maybe because both are not yet definitely defined? That is a >> good reason. > OPT just uses the reference model xsds I believe: > https://github.com/openEHR/reference-models/tree/master/models/openEHR/Release-1.0.2/XSD > > OET: There is a OET parser in the Java Implementation, see here: > https://github.com/openEHR/java-libs/tree/master/oet-parser > It also includes the xsds: > https://github.com/openEHR/java-libs/tree/master/oet-parser/src/main/xsd > - CompositionTemplate.xsd is the main one. The parser is then just > generated > > That said, OETs (or their equivalent) will be expressed pretty similar > to how specialised archetypes are expressed in ADL 2.0 source format I > believe - see here for a starting point: > http://www.openehr.org/wiki/display/ADL/ADL+1.5+templates+as+single+artefacts > >> >> I would like to see the formal XSD-definition the Template-designer >> works with and which results are published on CKM and used in several >> community-projects. >> Is that possible? I will take in account that they are not the >> definite version. >> > You can generate the TDS which I think you are referring to from CKM > directly for any COMPOSITION template. > Go to the Export Template tab for a Composition template, e.g. > http://openehr.org/ckm/#showTemplate_1013.26.2_EXPORT and download it > from there. It is generated for you on the fly. >> Another question: >> >> I wonder why there are two artefacts, OET and OPT. Both contain >> different information, but also have a part of overlap/redundancy. >> Isn't it possible to combine the two to one formal definition for an >> archetype? > OPT would be generated from OET+the archetypes. So essentially it is > combining archetypes and restricting them further. Not much different > to a specialisation of an archetype. So, compare OET as just listing > the differences and OPT as the full specification. OPT is just > generated from the oet + the underlying archetypes as required. During > deployment you are likely only interested in the OPT, but during the > development of archetypes & templates, you are much happier dealing > with a file format that just restricts the archetypes for your use > case, but which doesn't carry the whole information from the > archetypes - that would get you into a maintenance nightmare. > > Hope this helps and clarifies > Cheers > Sebastian > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >
