After discussion in Discourse, Slack and among editors, the following archetypes will be republished as a new major version.
At the same time, the following archetypes will be republished as a new minor version, to include the new major versions of the archetypes mentioned above as SLOT includes:
If you have any comments or objections, please note them here, at the latest before the planned publication date, December 23rd 2021.
Just an aside on this⌠I did a version compare on the first one between latest and the last .v1 version. I notice that the changes are main fixes to slot regexes. One of the new regexes (slightly altered for readability) is:
archetype_id/value =
openEHR-EHR-CLUSTER\.anatomical_location(-[a-zA-Z0-9_]+)*\.v1|
openEHR-EHR-CLUSTER\.anatomical_location_circle(-[a-zA-Z0-9_]+)*\.v1|
openEHR-EHR-CLUSTER\.anatomical_location_relative(-[a-zA-Z0-9_]+)*\.v2
The first two matches can be written more readably as:
openEHR-EHR-CLUSTER\.(anatomical_location|anatomical_location_circle)(-[a-zA-Z0-9_]+)*\.v1
so the modified result would be:
openEHR-EHR-CLUSTER\.(anatomical_location|anatomical_location_circle)(-[a-zA-Z0-9_]+)*\.v1|
openEHR-EHR-CLUSTER\.anatomical_location_relative(-[a-zA-Z0-9_]+)*\.v2
This change could be used globally in CKM archetypes and would make the slot choices easier to understand. This kind of change can be done as a patch change, since any regex evaluator will return the same result with both forms of pattern.
Just an idea for the future 
Does the CKM support the pipes? I tried doing this in the discussion in the other thread, and the CKM didnât finish the validation, but stopped at the pipe. @sebastian.garde
I prefer this original version. I know it is more verbose but it is way more readable and Iâm sure is much easier to implement.
CKM supports the pipes.
However the way CKM currently interprets any pipe as a separator for complete alternatives.
So the Ian-preferred full version should work ok (assuming all individual archetype id patterns are ok), whereas Thomas shortcut syntax would indeed not be fully validated.
The thing with all this is: It is easy to check if a given archetype id is matched by the given pattern. It is however, generally speaking, far more difficult to interpret any possible regex pattern and determine whether it is VDAFI conformant as a whole.
This is standard regex - does it mean that the Java (I assume) library / function for processing regexes in CKM doesnât fully implement regex?
Yes, that is standard regex and no, such a lib would be kicked out. 
The problem is not that I cannot take any given archetype id and say whether it is matching the regex or not.
That is exactly as simple as you make it sound.
The problem is that when validating VDFAI, I do not necessarily have any archetype ids to match against the regex.
The only thing that can therefore be validated is whether the regex can possibly match at least one syntactically valid archetype id.
And that does not seem quite as straightforward to me. I have worked it out more or less for current practice of regex usage for slots. However, making such a validation theoretically bullet-proof for all possible regexes in the slot is not possible as far as I can see. If this problem is trivial to you and I am missing something, please share the solution with me, and weâll implement it in CKM.
Now as I have said, I have worked it out for the existing typical regexes. However with âyourâ non-top-level pipes this has just become one extra step more complicated, because you need to do more checking to split the regex in its top-level parts (as separated by top-level pipes). Likely doable as well with extra effort, but not currently done.
You just want to test the validity of the regex, right - the usual approach (at least to my knowledge) is to try to compile the regex and if that works, then the regex is valid (doesnât mean it is ârightâ of course).
Stackoverflow provided this bit of code for Java:
import java.util.regex.Pattern;
import java.util.regex.PatternSyntaxException;
public class RegexTester {
public static void main(String[] arguments) {
String userInputPattern = arguments[0];
try {
Pattern.compile(userInputPattern);
} catch (PatternSyntaxException exception) {
System.err.println(exception.getDescription());
System.exit(1);
}
System.out.println("Syntax is ok.");
}
}
Right - I see what you are doing. Unfortunately I think youâll need to implement this, because anyone could write an archetype tool that creates slot regexes containing pipes below the âtop levelâ - CKM should die on anything that basic.
However, I think you can get away with counting â(â and â)â and as long as you are not inside any â()â, you are at the top level. So I think 4 or 5 lines of code will do it. How does this sound?
We might be in danger of letting the âmagic of regexâ pushing us way beyond the actual requirements, based on many years practical experience, Silje and I both agree that all we need is to be able to specifyâŚ
A specific âmandatoryâ archetype, including version number as the sole-slot fill (Actually not used in practice at all but there may be valid uses in the future)
much more commonly (in fact, right now universal) just define one or more archetype patterns as âsuggestedâ - these appear in green in AD, while other technically valid but not âsuggestedâ archetypes appear in grey.
occasionally exclude specific archetypes
with really only a couple of variations on that theme.
The tooling (and explanation) could be a lot slicker based on these requirements, and is essentially met right now. Just needs the v* handling fixed in AD, I think.
Re ensuring the regex is syntactically valid - ok, no big deal.
Counting ( ) would have been my idea of a âsolutionâ for top-level | as well to take this one step further.
BTW CKM is not dying in that case, it would just show you a (false positive) validation error you can however ignore if necessary.
I - of course - agree that what you are suggesting for a slot regex is valid, but at the same time I am not sure it is a good idea in practice. Ensuring that the main use cases are covered and use an agreed syntax where possible (as Ian suggests) that can be used by tooling to provide better explanations etc. seems far more powerful.
sure. I wasnât proposing anything earth-shattering - just a readability suggestion. Tools can obviously implement the functionality the way you say - as long as it is saved as valid regex, which is the published standard (including the ISO version of AOM), then everyone will be happy.
Where do I find the diff view off the changes in these minor revisions? (Couldnât find it on CKM archetype history.)
Iâm curious about the versioning, if these 2 archetypes now include a new major version of the included archetypes (and the previous version is no longer included) thatâs a breaking change and thus a new major, right?
And if it doesnât (and the previous version is still a valid include) and itâs just a suggestion, wouldnât it be a patch update?
It doesnât really matter off course, Iâm just working on my understanding of openEHR versioning:)
My understanding is that this is not a breaking change because you are essentially widening/loosening the slot constraint.
This at least would be consistent with other elements: widening a constraint - and thus allowing more possible data - is not a breaking change. The other way round (towards more restrictive), it is breaking because the new archetype revision is not guaranteed to be able âreadâ the data of the previous revision.
(At least for normal elements. Whether this would be the same for Slots is another discussion maybe, but - from memory - how we have it currently defined in CKM as well.)
Sorry, I hadnât gotten around to making those changes yet. Here they are:
Iâm not sure it is, because nothing is excluded in either of the revisions. Theyâre just suggestions.
The CKM thinks itâs a minor revision. For this particular change, and strictly semantically speaking, itâs probably a patch. But Iâm not going to argue with the CKM about it. 
I agree with @sebastian.garde on this. Weâre loosening the constraints, so all pre-existing data made using the previous constraints are still valid with the new constraints.
Republished! Merry yule! 
