Martin van den Bemt wrote: > For us it doesn't matter. It will have some pretty big consequences > for our implmentation, since we currently assume a DVText everywhere > in the code. Since we are behind on the specs anyway (meaning not > really keeping up), this won't yet be integrated, untill we have a go > at catching up with the changes made to the specificion.
Martin, presumably your implementation is locked at an earlier baseline of openEHR around 0.9? > > We would like to see some kind of deprecation however for changes to > the openehr model, since it currently is already a very big puzzle for > us to be able to use the new specs. Maybe it will somewhat clutter > the specs, but currently we have to start downloading/tracking older > revisions of the spec to get to what we implemented. Do you mean you want to keep all previous details intact in the specification documents? I think we have a reponsibility to publish the latest version of any specification in a "clean" form for new implementors - after all the latest version is "the specification". If you look at the changes that have been made, there are currently 125 or so change requests - some of which have changed the way we present the material, some of which change the structure of the model. Now, the intention is that such changes will diminish over time, with the forthcoming release 1.0 being a stable release. And of course, there cannot be ongoing chopping of changing of the basic models. However I think we are still in a phase where we are getting feedback from implementors about what works and what doesn't. I think it would be resonable to do what you say after the release of 1.0, and we will look into how this should be done. At the moment, we have tried to a) supply detailed CRs online and b) be careful to document all changes in the revision histories of the specifications and c) make sure that all the specifications compile in our modelling environment, before publishing them. It does mean that implementors have a certain responsibility to read the CRs (particularly the page http://www.openehr.org/repositories/spec-dev/latest/publishing/CM/CRs/CR_by_release.html) and the revision histories of documents. A new CR/PR system will make CRs more accessible, and the CM plan has been rewritten. What would help us is better feedback from implementors - it has been hard to determine how many developers are at what stage in implementation, and therefore what impact any change will have. Hopefully the new "implementers" list will help that; other suggestions are welcome. Another thing we will release in the next couple of months is a textual rendition of the entire RM and Archetype Model in XML form, using a UML 2.0 tagset. This expression of the model will be lossless from the specifications, and can be used to generate or validate other deliverables, such as XML-schemas, programming language interfaces, relational database schemata and so on. > Example is the table_s which was renamed to item_table (with a whole > new inheritence tree) in the specs, finding the right spec gave us a > hard time (we didn't have the time to refactor everything to use the > new structure). This change happened quite a while ago now - I would have thought nearly 2 years ago, but I would have to check that. Do you mean that it wasn't easy to work out what had changed? Suggestions on how to better provide such information are welcome. > > You say : > This CR has passed, and the changes been made and tested in software > but not released. > > Which software and how was it tested ? all modelling changes are made to the openEHR Eiffel model environment, compiled and tested in a basic way. This environment is used because it is the closest to UML that actually implements all UML semantics, particularly class invariants and pre- and post-conditions (otherwise known as "contracts"). I don't mean to imply that whole systems have been built with each change by openEHR - of course it doesn't have the resources for that. But most other specifications - standards - in the world are not even validated before being published, and so there is not even a minimum guarantee of implementability or coherence. In the future, with reference software implmentations in existence, we would use those to test changes before releasing them. This will include the emerging Java reference model implementation, XML-schemas and so on. hope this helps. - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
