SPECBASE-42 Define TEMPLATE_ID aligned with HRID

[SevKohler]

This is a first PR including the changes, this is to be discussed

[gardes]

I am not familiar with all that has been discussed so take my comments with a grain of salt

[gardes]

I would suggest to remove "Lexical form to be determined." now that it is determined.

[gardes]

Are you sure the namespace part of the regex is ok?

I am not familiar with all that has been discussed but a couple of observations:

1. It seems like it must have a dot at the end of the regex before the :: separator. This seems unintuitive/wrong
2. Do we really need the characters .:/&?=+ within the namespace?
3. It seems to allow any number of subsequent "." after the first character which seem counter-intuitive.

Maybe something like this regex works better as a replacement:
(?<namespace>(?:(?:[a-zA-Z_][a-zA-Z0-9_-])(?:.[a-zA-Z_][a-zA-Z0-9_-])+]*)+)::

This would enable org.openehr, org.highmed com.my-test or uk.org.my_organisation.
However unlike the above regex, o....-..c&/=+._ would not be supported as an extreme example of a namespace supported by the current namespace suggestion.

Also, should it not be "matches" instead of "not matches"?

[SevKohler]

Im not sure, i just made the PR so we have something to work on and move the progress.
Thanks for the input. I copied actually your regex from the comment on confluence.
Can you provide me with the full one ?
I did now:

matches("^(?<namespace>(?:(?:[a-zA-Z_][a-zA-Z0-9_-])(?:.[a-zA-Z_][a-zA-Z0-9_-])]*))::)
(?<rm_publisher>[a-zA-Z])-
(?<rm_package>[a-zA-Z][a-zA-Z0-9_])-
(?<rm_class>[a-zA-Z])\.
(?<concept_name>[a-zA-Z][a-zA-Z0-9_-])\.
(?<release_version>v\d+(?:\.\d+){0,2})
(?:-(?<version_status>))?
(?:\.(?<build_count>\d))?$
")

I think your right and it should be matches

[gardes]

Hmm, I think a few required + went missing somewhere and there is an unmatched parentheses after :: and a dot that needed escaping and the version_status regex part that was missing.

Let me try again in total:

matches("/^(?<namespace>(?:[a-zA-Z][a-zA-Z0-9_-]*)(?:\.[a-zA-Z][a-zA-Z0-9_-]*)+)::
(?<rm_publisher>[a-zA-Z]+)-
(?<rm_package>[a-zA-Z][a-zA-Z0-9_]+)-
(?<rm_class>[a-zA-Z]+)\.
(?<concept_name>[a-zA-Z][a-zA-Z0-9_-]+)\.
(?<release_version>v\d+(?:\.\d+){0,2})
(?:-(?<version_status>[a-zA-Z0-9]+))?
(?:\.(?<build_count>\d))?$
")

Please see https://regex101.com/r/vLdk5l/2 to confirm that this is what you want - you can just add more test strings, one per line to see whether they match or not.

[wolandscat]

Everyone should note that if you change a file like template_id.adoc you are changing a generated file. Changes will be wiped out on next regen from MagicDraw. With no regenerate, we are accumulating formal changes that are expressed at text mods to a rendered output precursor file (adoc)., not a model file of any kind.

[SevKohler]

Do you mean that these ascidocs are also generated over MagicDraw not only the UMLs ?
Or how does this work.

This whole construct seems very intransparent to me and most of the spec people :(
Maybe its time we move the spec over to something accessible and modern.

[wolandscat]

The models have been maintained in MagicDraw for about 12 years from memory. All of the files in the directory docs/UML/classes are generated by the UML extractor. It's modern enough, and has worked very well.

But I fear there is a lack of knowledge about this pathway, and some people are unwittingly creating PRs to those generated files. All such changes will be lost the next time I or anyone regenerates from MagicDraw. I have posted quite a few times about this, but not sure if people are reading it.

There has been a lot of discussion about moving from MagicDraw to e.g. PlantUML, but there's significant work involved. We probably should do it, but we need to plan for a transition period.

[SevKohler]

Okay, on monday there is the spec meeting, we may discuss it there.
Where do i need to alter the fields in order for them to be generated ?
In the computableUML ?

[wolandscat]

Yes it's via the UML tool. I need about a week to figure out licenses for openEHR and then we can do that.

[joostholslag]

We should add a text, that states that any (legacy) template_id.value string that matches the regex for HRID is considered an HRID, including the assumptions around semantic versioning.

[joostholslag]

See https://openehr.atlassian.net/jira/software/c/projects/SPECPR/issues?jql=project%20%3D%20%22SPECPR%22%20ORDER%20BY%20created%20DESC
and: https://openehr.atlassian.net/browse/SPECBASE-42?focusedCommentId=31104
So we (me, @SevKohler or anyone) now need to do the changes in .adoc (and later in BMM).

[joostholslag]

I changed the description to reflect the latest consensus. Jelte Zeilstra will suggest a definition for the function (instead of the invariant).
TODO:

• 1. update UML/BMM (later)
• 2. update function name if different from current
• 3. consider changing link to refer to ADL grammar instead of AOM class.
• 4. check styling (links, class name capitalization).

[joostholslag]

I changed the description to reflect the latest consensus. Jelte Zeilstra will suggest a definition for the function (instead of the invariant). TODO:

• 1. update UML/BMM (later)
• 2. update function name if different from current
• 3. consider changing link to refer to ADL grammar instead of AOM class.
• 4. check styling (links, class name capitalization).

@sebastian-iancu @wolandscat could you help re 3 and 4 please?

[SevKohler]

how do we mark this in the jira then ?
I would suggest we make one template_id hrid issue and then link two smaller ones to it so we dont block the other PR.

[joostholslag]

In jira the CRs need to be per spec (am and base). The PR (problem report) can be singular.