I have raised 2 changes wrt archetypes (wrt regex'es and superclass
content in subclasses) & a thought occurred which had been troubling me
for a while which is:
Where exactly are these changes made/agreed to etc?
i.e. wrt say HL7 (or other std orgs I have been involved with (e.g. the
W3C) there are technical committees where I would put these changes,
possibly there would be a trac/bugzilla so that things don't "slip off
the radar", votes would be taken & recorded etc.
I have been looking at the java archetype code & have been considering
putting some time in there but.....how would I know that the code is up
to a given standard (e.g. say if the regex requirement was changed or
the super/subclass thing was resolved) given I can find no such committee?
i.e. if changes were agreed to then the java tools, ocean tools etc
should all produce the same results.
This can only be the case if the changes/standards etc are out in the
open such that coders can have sufficient pre-warning of impending
changes (or indeed possibly wholly new structures) in advance so that
different tooling in different languages by different groups be the
coordinated.
i.e. if I were to generate XML from ADL using the ocean tools will I get
the same result as if I were to wrap the java tools as ant tasks & use
them for the same purpose? How would I know?
I have raised 2 changes wrt archetypes (wrt regex'es and superclass
content in subclasses) & a thought occurred which had been troubling me
for a while which is:
Where exactly are these changes made/agreed to etc?
i.e. wrt say HL7 (or other std orgs I have been involved with (e.g. the
W3C) there are technical committees where I would put these changes,
possibly there would be a trac/bugzilla so that things don't "slip off
the radar", votes would be taken & recorded etc.
The changes to the RM,AM, etc are handled by the Architecture Review
Board (ARB).
I have been looking at the java archetype code & have been considering
putting some time in there but.....how would I know that the code is up
to a given standard (e.g. say if the regex requirement was changed or
the super/subclass thing was resolved) given I can find no such committee?
This can only be the case if the changes/standards etc are out in the
open such that coders can have sufficient pre-warning of impending
changes (or indeed possibly wholly new structures) in advance so that
different tooling in different languages by different groups be the
coordinated.
This is certainly the case as you'll see from the above links.
i.e. if I were to generate XML from ADL using the ocean tools will I get
the same result as if I were to wrap the java tools as ant tasks & use
them for the same purpose? How would I know?
Currently the groups who work on the specifications are formed by those
who are interested registering on the wiki page / or with the team lead.
All changes large or small are documented by CRs, and all CRs are
publicly online at the Jira server - http://www.openehr.org/issues . You
can look here at any time and see the current status of CRs in the next
release (the next release right now is 1.0.2).
openEHR doesn't use a committee structure like the standards bodies
because we have not found it useful for developing good quality
engineering specifications or implementations. (It is also very
expensive in time, money and costly for the environment). Committees
might one day be created for review purposes, but the implementation
community already performs the main role here. (Personally I think
official standards organisations would be far more useful by providing a
review function on IP developed elsewhere by proper
analysis/design/build processes than trying to create their own IP,
which is generally not very good. This is how ISO, IEC, CCITT and many
other SDOs worked in the past. Somehow some of them have become confused
about their role and competence in the e-health space.)
With respect to what standard a given piece of software adheres to, it
will always be one of the official releases of the openEHR
specifications. You can always see a detailed view of each release here: http://www.openehr.org/issues/browse/SPEC?report=com.atlassian.jira.plugin.system.project:changelog-panel
(this link is Home page > Specifications > Change History). It is up to
the project team releasing the software to indicate which release the
software conforms to. So for example, if two different archetype editors
both implement Release 1.0.1 ADL specification (ADL 1.4) then they
should be able to communicate .adl and .xml archetypes. This is indeed
currently the case.
This community has grown organically and has been very focussed on quality outcomes. I believe we provide a good way of processing change requests much as we all do inside software houses. We have an expert group (which includes John Arnett) which is currently considering CRs for 1.0.2.
Generally we hope the community will raise issues on the lists which will be discussed. You have done this with the regex and that is the way to go. You can wait for responses. None will either mean it is not on other people’s radar or it is seen as coming from a different space and is not understood.
You can add a problem report or a change request here and the ARB will consider it. You can lobby members of the ARB to get a response if you want.
So it is not a balloting process - just as most open source projects are not. It is an expert led process and once people have been at it for a while they might like to take a turn on the ARB (or CRB). The governance board (which is being expanded to include wider input) will choose the ARB and CRB. It is not democratic, although quality input is universally appreciated.
Your enthusiasm for XML is appreciated and I am sure we can do a lot to the Schema for archetypes to make them easier to work with. At present it is a dump of the AOM. This might make your regex processing easier for example.
The aim is to make sure we stay in a quality space and we incrementally improve what we have. The RM and AOM need to be stable - more stable than Thomas would like them to be at times.
I hope this throws some light on the process. We want it to be better and we know that people feel a little outside the endeavour at times but I am sure as you get to know us you will understand why it goes like it does at least at this stage.
