# Archetypes - regex question **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2008-06-12 06:14 UTC **Views:** 1 **Replies:** 10 **URL:** https://discourse.openehr.org/t/archetypes-regex-question/14763 --- ## Post #1 by @Adam_Flinton Dear All, Could you explain a little piece of expected beahviour to me wrt including/allowing one archetype to include others A\) If the include is a list of regex's matching archetype names etc e\.g\. /checklist\_item\-general\-cvs1\\\.v1|checklist\_item\-general\-cvs2\\\.v1|checklist\_ item\-general\-cvs3\\\.v2|checklist\_item\-general\-cvs4\\\.v2draft|checklist\_item\-ge neral\\\.v1|checklist\_item\-general\\\.v2|checklist\_item\-general\\\.v3/ & the exclude is: /\.\*/ Then\.\.\.\.\.\.I include those that match the include but exclude all others? If so surely that is exactly the same as not having the exclude /\.\*/ at all\.\.\.\. or\.\.\. if the exclude says exclude all\.\.\.\.do I simply exclude all? B\) The reverse\. i\.e\. the iinclude says /\.\*/ & the exclude is a list of regex'es \.\.\.\. What then? TIA Adam --- ## Post #2 by @system Hi Adam This is another example of the approach to be as specific as possible. The exclude statement can be used to exclude specific archetypes and the Include ALL in this case means that all others are allowed. If the Exclude ALL statement is added to an archetype, it means ONLY those specifically stated can be added. The issue here is backward compatibility and new archetypes. The include will generally be seen as the appropriate list but others could be added if they arise and are required (the list is not closed). Tony Shannon has argued (along with me) that this should be the default (ie we do not usually know that it would never be appropriate to add another archetype here. Is that helpful? Do you think this is useful? It does mean there is no need to reversion archetypes if new ones might fit in a cluster (which is also useful). Cheers, Sam Adam Flinton wrote: [details="(attachments)"] ![OceanInformaticsl.JPG|183x82](upload://2lcnRHcC3QqDv6AeaDZuo8M9Qlv.jpeg) [/details] --- ## Post #3 by @williamtfgoossen In a message dated 13-6-2008 19:10:07 W. Europe Daylight Time, sam.heard@oceaninformatics.com writes: We are getting into dangerous options here: include all and exclude all in a time series where 'all' definitely changes both with respect to revisions of the existing ones, deletions and new to be added might lead to inconsistent calls to archetypes over time. I believe such constraining should not take place on the archetype over archetype level, but at the (OpenEHR) template level. In here you can be explicit in what is to be included or excluded. > Hi Adam > > This is another example of the approach to be as specific as possible. The exclude statement can be used to exclude specific archetypes and the Include ALL in this case means that all others are allowed. If the Exclude ALL statement is added to an archetype, it means ONLY those specifically stated can be added. > > The issue here is backward compatibility and new archetypes. The include will generally be seen as the appropriate list but others could be added if they arise and are required (the list is not closed). Tony Shannon has argued (along with me) that this should be the default (ie we do not usually know that it would never be appropriate to add another archetype here. > > Is that helpful? Do you think this is useful? It does mean there is no need to reversion archetypes if new ones might fit in a cluster (which is also useful). > > Cheers, Sam Sincerely yours, dr. William TF Goossen director Results 4 Care b.v. De Stinse 15 3823 VM Amersfoort email: Results4Care@cs.com phone + 31654614458 fax +3133 2570169 www.results4care.nl Dutch Chamber of Commerce number: 32133713 --- ## Post #4 by @system William, It is potentially dangerous ground. But ... - Archetypes express what can be documented about a specific topic. Since such a 'Real Archetype' can or will consist of re-usable patterns, 'Real Archetypes' consist many times of a collection of sub-archetypes that express recurring patterns of documentation. In other words archetypes can and will be nested. And there must be a way to specify what archetypes are part of the ensemble at what spots. - It will create the problem for Archetype Governance. We need to have rules and ways to manage and enforce them. This needs a tool. Ocean Informatics, for this purpose, has developed the Archetype Knowledge Manager. Gerard > We are getting into dangerous options here: include all and exclude all in a time series where 'all' definitely changes both with respect to revisions of the existing ones, deletions and new to be added might lead to inconsistent calls to archetypes over time. > > I believe such constraining should not take place on the archetype over archetype level, but at the (OpenEHR) template level. In here you can be explicit in what is to be included or excluded. -- -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: [gfrer@luna.nl](mailto:gfrer@luna.nl) Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 --- ## Post #5 by @system Hi William This only applies to slots - not to events, so the problems you allude to in regard to timing could not arise. Closing slots is a problem for backward compatibility and, as you point out, should probably be left to templates. But documenting archetypes that are known to fit the slot at design time is knowledge worth capturing. Cheers, Sam [details="(attachments)"] ![OceanInformaticsl.JPG|183x82](upload://2lcnRHcC3QqDv6AeaDZuo8M9Qlv.jpeg) [/details] --- ## Post #6 by @Andrew_Patterson > This is another example of the approach to be as specific as possible\. The > exclude statement can be used to exclude specific archetypes and the Include > ALL in this case means that all others are allowed\. If the Exclude ALL > statement is added to an archetype, it means ONLY those specifically stated > can be added\. Sam, without putting words in Adams mouth, I think he was asking about the precedence of include/exclude sections\. It is a common problem is coming up with rule system like this \- for instance one can look at the allow/deny pattern of the apache2\.conf file for how to setup IP address ranges\. In the apache case, there is an explicit clause that allows the order to be changed \- either allow first then deny, or deny first then allow\. In the ADL spec, this is mentioned as a "yet to be defined" \(section 5\.3\.8\)\. Andrew --- ## Post #7 by @thomas.beale Andrew Patterson wrote: > Sam, without putting words in Adams mouth, I think he was asking about > the precedence of include/exclude sections\. It is a common problem is > coming up with rule system like this \- for instance one can look at the > allow/deny pattern of the apache2\.conf file for how to setup IP address > ranges\. In the apache case, there is an explicit clause that allows the > order to be changed \- either allow first then deny, or deny first then allow\. > > In the ADL spec, this is mentioned as a "yet to be defined" \(section 5\.3\.8\)\. >   Indeed\. I don't think the requirements have been adequately defined, so this remains one of the few little holes to plug properly in ADL\. \- thomas --- ## Post #8 by @Adam_Flinton Sam Heard wrote: > Hi Adam > > This is another example of the approach to be as specific as possible\. > The exclude statement can be used to exclude specific archetypes and > the Include ALL in this case means that all others are allowed\. If the > Exclude ALL statement is added to an archetype, it means ONLY those > specifically stated can be added\. So if the include is ALL & the Exclude is ALL \(as I believe one can do in the tool\) that would be the same as Include ALL? > > The issue here is backward compatibility and new archetypes\. The > include will generally be seen as the appropriate list but others > could be added if they arise and are required \(the list is not > closed\)\. Tony Shannon has argued \(along with me\) that this should be > the default \(ie we do not usually know that it would never be > appropriate to add another archetype here\. > > Is that helpful? Do you think this is useful? It does mean there is no > need to reversion archetypes if new ones might fit in a cluster \(which > is also useful\)\. I am a little concerned with the overlap twixt the Archetype editor & the template editor in that in the template editor, unless one excludes all then one can add what ever archetype you want to a given archetype in whihc case\.\.\.\.what's the point of doing so in the archetype editor? i\.e\. I can see a division of labour occuring where a core team defines archetypes & then a team working with hospitals etc define the archetypes\. Were that to be the case & were the core team to say "this archetype can only contain\.\.\.\.\." then they might get concerned if template designers can then go ahead & include any they feel like\. Adam \. --- ## Post #9 by @Adam_Flinton Williamtfgoossen@cs\.com wrote: > In a message dated 13\-6\-2008 19:10:07 W\. Europe Daylight Time, > sam\.heard@oceaninformatics\.com writes: > > We are getting into dangerous options here: include all and exclude > all in a time series where 'all' definitely changes both with respect > to revisions of the existing ones, deletions and new to be added might > lead to inconsistent calls to archetypes over time\. > > I believe such constraining should not take place on the archetype > over archetype level, but at the \(OpenEHR\) template level\. In here you > can be explicit in what is to be included or excluded\. > Fine by me\.\.\.\.\.I don't mind where such restrictions occur, simply that they not occur in 2 different places where an archetype says "can only contain B or C" but the template says "contains D,E,F or G"\. Adam --- ## Post #10 by @Adam_Flinton Thomas Beale wrote: > Andrew Patterson wrote: >   >> Sam, without putting words in Adams mouth, I think he was asking about >> the precedence of include/exclude sections\. It is a common problem is >> coming up with rule system like this \- for instance one can look at the >> allow/deny pattern of the apache2\.conf file for how to setup IP address >> ranges\. In the apache case, there is an explicit clause that allows the >> order to be changed \- either allow first then deny, or deny first then allow\. >> >> In the ADL spec, this is mentioned as a "yet to be defined" \(section 5\.3\.8\)\. >>   > > Indeed\. I don't think the requirements have been adequately defined, so > this remains one of the few little holes to plug properly in ADL\. > > \- thomas > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > openEHR\-technical mailing list > openEHR\-technical@openehr\.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >   I am assuming allow then deny i\.e\. include all, exclude all = include all\. Otherwise\.\.\.exclude all becomes somewhere between pointless & dangerous\. Adam --- ## Post #11 by @Peter_Gummer1 Adam Flinton wrote: > > I am assuming allow then deny i\.e\. include all, exclude all = include all\. > > Otherwise\.\.\.exclude all becomes somewhere between pointless & dangerous\. I think of it in terms of items moving back and forth between an "include" list and an "exclude" list\. \* Initially, the slot is completely unconstrained\. Therefore, all archetypes are in the "include" list\. \* Excluding some archetypes shifts them to the "exclude" list\. \* Excluding all shifts all archetypes into the "exclude" list\. \* Including some archetypes overrides exclusion, moving them back to the "include" list\. \* Include all shifts all archetypes back into the "include" list\. So it's basically a three\-state process: 1\. All initially included\. 2\. Move some \(or all\) to the "exclude" list\. 3\. Move some \(or all\) back to the "include" list\. This seems to be the behaviour that we observe in Ocean's Template Designer\. In particular, this way of conceptualising it is consistent with how including has no effect unless you also exclude all; and it is also consistent with your hope, Adam, that include all should override exclude all\. It also means that "include all" is rather pointless, doesn't it, because doesn't "include all" have exactly the same effect as not constraining it at all? Maybe it would be clearer if there was only one list\. It could have worked like this, I think: \* By default, the list would be an "exclude" list; i\.e\. it would serve to constrain the slot by specifying that certain patterns be disallowed\. \* There would be an option to treat it as an "include" list; i\.e\. only the specified patterns would be allowed\. \* There would be no need for the "all" options\. They would be redundant, because "include all" would be the same as not constraining it at all, and "exclude all" would be the same as an empty "include" list\. Unless there's something I don't understand about how it is meant to work now, this suggestion would give us most of the power of the current arrangement, minus the confusion\. \(The only capability that we would lose, that I can think of, would be the ability to exclude a proper subset of the archetypes, but then to re\-include a subset of that subset: e\.g\., to exclude "problem\-\.\*", but then to re\-include "problem" itself\. Do we really need such fine\-grained control?\) \- Peter --- **Canonical:** https://discourse.openehr.org/t/archetypes-regex-question/14763 **Original content:** https://discourse.openehr.org/t/archetypes-regex-question/14763