Well the problem here is that the specifications don't actually say anything about the regexes, or even that you have to use regexes to identify archetypes in slots - it is just one way of doing it. So any tools today that take a particular approach to regexes are already outside the standard.
I think what we should probably do is to state that regexes, if used, must be assumed to be usable as a filter on whole archetype ids without prior modification. This still does not prevent some tool using the short regexes now in use in the archetype editor, since the clearly can be used at a technical level - it is just that they might create errors. And there may be some short patterns which are actually correct. I'm not sure how we can formally state this.... - thomas Peter Gummer wrote: > Thomas Beale wrote: > >> I also agree with Adam. A regex should be able to be used over a >> population of strings (identifiers in this case) and have the effect of >> filtering out what you want. ... >> >> Practically speaking this does not change the specifications, but I >> suspect we should put some guidance in to the effect that regexes based >> on full identifiers should be used in archetype slots. >> >> > > > Surely the specifications should be stronger than just guidance. > Existing tools that are massaging the regex will cease to work if they > are given a full regex. It would be a breaking change, so I think it > should be spelled out in the specification. Otherwise, tools are going > to have to try to do some clever guesswork to decide whether a given > pattern is intended to match the full archetype id or just the domain > concept part of it. > > - Peter > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > -- *Thomas Beale Chief Technology Officer, Ocean Informatics <http://www.oceaninformatics.com/>* Chair Architectural Review Board, /open/EHR Foundation <http://www.openehr.org/> Honorary Research Fellow, University College London <http://www.chime.ucl.ac.uk/> * *
