Hi.
Many thanks to great contributors !
I’m Seung-Jong Yu and not a newbie but kind of lurker
I can’t categorize my topic, so post here.
I have some OPT-related questions while I’m making some templates and export it in OPT using Better’s Archetype Designer.
Here are questions.
OPT of Better’s Archetype Designer has some unknown attributes and omits those (via Cabolabs’ Operational Template XML Validator). For example, the former are “matches_negated” , “Ontology” and “component_ontologies”, the latter are “<node_id/>” and "<view>…</view> ".
Do those follow the openEHR specification? If yes, gap in different OPT versions?
For checking 1), I am searching OPT document and schema. But I have not found any clues in various resources yet. Then is below right?
(1) The link of OPT1.4 is dead ,but from other threads, there is no link now, so if I have question, a specific question needs to be posted on this forum. And OPT2 document is not finalized.
I cannot contribute much to this, but since you asked, I’ll share what little I know:
I can’t remember seeing matches_negated before.
Re ontology: this seems to exist as a separate element, but I am not sure I have seen this used. It seems you can just add term_definitions etc. directly to the definition in the opt14 and this seems to be what is done instead of separating this out into ontology and component_ontologies. Not sure if this is just interchangable. But if so, I would have expected the term_definitions etc. to be underneath, whereas in your example it is just the archetype ids on their own…This is probably syntactically ok, but not sure what purpose it would serve?
Hi, I don’t know if the schemas are being correctly versioned right now, but for OPT 1.4 validity you can check them on the openEHR Toolkit that validates against the OPT 1.4 XSD https://server001.cloudehrserver.com/cot/
I mentioned on another thread that the Marand tools might generate OPTs differently from the Template Designer, and also might be different to the OPT 1.4 XSD.
Ontology, component ontology and views were definitely introduced by the Ocean Template Designer so it is possible that the XSD has not been updated
I’m not sure about <match_negated> @borut.fabjan@matijap - any idea what this is for in the .opt? It is certainly not in the Ocean .opt that I can see.
The .opt generated by CKM (which based on an Ocean webservice, which should match TD behaviour) does contain the
Compared to the Better .opt it also does not contain and <component_ontologies> but I have checked and I know that TD definitely used to generate these elements. They are used to carry multiple languages within an .opt. I suspect the difference is that the Better version is always to generate these elements, even if the template carries only a single language, whilst Ocean generate it only when there are multiple languages.
So the upshot is that I think the only real difference in the two formats is <match_negated> which Better seeme to have introduced, and that the .xsd that Pablo has (and I think this was the only one that could be found) does not reflaect some other more recent changes (at least 5 years old) in .opt generation, whoich are in fact common to both Better and Ocean.
The issue I see is we don’t have a managed versioned environment for OPT XSDs, so everyone might be using a slightly different OPT structure. We need to know what is OPT 1.4 XSD v1.0 and what is OPT 1.4 XSD v2.0, and that should be differentiated from OPT 2.0 XSD v1.0 (note we have two versions of the OPT spec and different versions and revisions for the correspondent XSDs for each OPT version, and AFAIK no XSD is currently versioned so we don’t know what we are using, or what is current). This should be formally defined, “common practice” or “recent changes” is not a formal versioning system
Also AFAIK, this wasn’t discussed in the SEC and IMO should be a priority to avoid confusing devs.
Completely agree Pablo. It is confusing for relative outsiders (and some of us insiders!!). The good news is, I think, that for practical purposes there is not a major issue - the various differences in actual .opt formats are pretty minor and any ‘real’ incompatibilities seem to have been resolved between Ocean and Better’s tooling.
The real issue is that the formal .xsd has not kept up with ‘de-facto standard’ usage and I suspect is not used internally by either Ocean or Better.
Id be happy to help pester tooling suppliers if someone (hello Pablo!!) could have a go at updating the .xsd to reflect current usage.
Support ontology and component ontologies (Better and Ocean)
I guess we need, before updating anything, to establish a versioning scheme and identify different XSDs around as different versions of the same initial XSD, which I would say is v1.0
So the main thing would be to gather XSDs differnt implementers are using and do a diff to check what they have added, then say “this is v1.0, that is v1.1, etc”, after that, agree with them to use that version number/semver.
After that, I would also ask implementers to manage change requests in the main repo to avoid local changes, so the SEC can manage versions and releases.
Also would be useful to identify which XSD version is used on different modelling tools to avoid issues, which we are having right now between Ocean and Marand tools. In LinkEHR I think you can upload any XSD and work with that, would need input from @yampeku
Currently support to OPT in LinkEHR is handcrafted. If I remember correctly, I found some parts in OPT that weren’t in the XSD Pablo provided me back in the day, so kind of reverse engineered it.
On other matter, XSD import in LinkEHR is restricted to RM creation or data source definition for mapping.
Probably they can be supported with not too much work, as more or less everything should be there. If it changes completely then more work would be needed.
I’m not sure we need ot support multiple versions, just a latest version, then properly handle it from there. In practice , things seem to be working pretty well without a ‘current’ XSD, and TBH if the tooling vendors are not rally using an XSD internally it is going to be quite tricky to find/pin-down older versions.
We basically have 3 ‘public’ tooling vendors
Better
Ocean
LinkEHR
Right now Better / Ocean are virtually aligned, in working practice i.e the .opts are interchangable other than for some minor differences. Let;'s sort out those differences. document them, and cross-check with LinkEHR and go with that as the baseline. Then govern properly from now on?
Let’s be careful not to waste too much energy on an issue which I agree should be fixed but is not actually a practical problem right now for working tooling.
Probably need to check with @sebastian.iancu who did a lot of work organising XSDs; don’t know whether he got a definitive one for the OPT 1.4, but the only things anyone should be using are in the specifications-ITS-XML Git repo. I don’t see an OPT XSD in there, but if we have a candidate, let’s put it in.
That’s the problem - the only candidate that anyone could identify is the old version that Pablo has. It is out of date but the new aspects have mostly been in place for a long time - that version just needs updated to reflect what is actually a high degree of alignment in .opt.
I don’t think we need to “support” but to start “tracking” changes. Support means maintaining old versions, what I was referring to was to detect changes between versions and assign a version number to each one, then keep maintaining the last one, but have all the XSD versions under one versioned environment.
This is very easy thing to do, and I can do it, we just need the XSDs each provider is using, I can merge the XSDs into one file (xmlHelpline.com: tools) then do a diff comparing 2 by 2 and noting the changes. The file with most changes will be the latest version, and I guess the one I have imported in 2015 is the first version.
Also this comparison will let us know if there are any incompatibilities between the XSDs out there, that is a more difficult thing to solve since different implementations might rely on different rules. That is why we can’t just keep track of the latest version only: implementations using incompatible XSDs will be forced to adapt and that might not be possible. Incompatible means some element is required by the new schema but was optional or didn’t exist on a previous one.
Would it be possible to get the XSDs from Better and Ocean?
BTW the one I have is a merge from the multiple modular XSDs I found back in 2015, just because working with one file is easier than working with many. But I might have the original files somewhere on an old VM.
