Hi,
Since that it is so that some extract-classes derive from Locatable, they can be used to use them as RM-class for an archetype-definition.
But how would the ArchetypeId look like, special the rmName. Would it be something like openEHR-Extract-Extract........ ?
Thanks in advance for answering
Bert
Hi Bert,
I would say that the “rm name” would be “EHR_Extract”, as it is the way the package is called in the documentation http://www.openehr.org/releases/RM/latest/docs/ehr_extract/ehr_extract.html (notice that demographics and EHR are the other package names).
After that you would put the corresponding class name to constraint
Regards
Having said that, I’m not sure current regex for archetype ids allows the use of spaces or undescores on the rm part. I’ll have to check that
Thanks Diego, that seems a good suggestion based on good reasoning.
Bert
The test package is called “test_pkg” at least in adl2 – so underscores are supported.
Pieter
I was too fast with my compliments 
In that case, we can leave the underscore out, It remains readable. Bert
underscore it is then! 
Quick and firm No objections Bert
The ADL 1.4 identifier syntax is here, and permits underscores. The ADL2 syntax for the type ARCHETYPE_HRID I think is not visible anywhere except code, so we’ll need to remedy that. The relevant code shows that underscores are accepted as well.
I would suggest using the proper specification name as various tools are starting to depend on consistent use of names across specifications, UML packages and classes, and archetypes. In fact I suspect that right now the ADL Workbench would not recognise an Extract archetype that didn’t have EHR_EXTRACT as the RM class qualifier, because the relevant BMM is named that way (I haven’t checked though).
I would go with the id template openEHR-EHR_EXTRACT-EXTRACT.something.v1.0.0. There are examples already of this in the archetype test repo.
I spoke too fast - the ARCHETYPE_HRID syntax is specified here in the Archetype Identification spec.
So, there are also considerations I did not see.
I can live a few days more without having a definite policy
But the classes are there and people will want to use them.
I think Thomas proposal is in line with the other rmNames, like EHR and DEMOGRAPHIC (which are capitalized), and therefor indeed EHR_EXTRACT seems to me the best solution. Sorry for agreeing with previous suggestions.
Bert
I think the string matching should be case-insensitive, and the current regexes allow for any case. Various tools implementers would need to check to see if their tools match 'ehr_extract' to 'EHR_EXTRACT' etc.
- thomas
I think the string matching should be case-insensitive, and the current regexes allow for any case. Various tools implementers would need to check to see if their tools match 'ehr_extract' to 'EHR_EXTRACT' etc.
This is like Diego and Pieter also suggested.
Okay, thanks.
I agree about the case insensitivity. Archie still does this case sensitive, so I just created https://github.com/openEHR/archie/issues/8 (
Pieter
I think the string matching should be case-insensitive, and the current
regexes allow for any case. Various tools implementers would need to
check to see if their tools match 'ehr_extract' to 'EHR_EXTRACT' etc.
- thomas
Note that for class and property names, we tend to stick to typical programming convantions, which is
One reason to do this is to be able to distinguish a class name on its own, e.g. in an ADL archetype, and not mix it up with a property name. The ADL workbench does this, and I would argue we want to keep these rules.
Nothing is ever completely simple…