Just to be clear - it was just a draft i.e. in development - there was never any release - that’s why we have created this BASE 1.0.4 release retrospectively. (Here’s the last commit to BASE that contained the old Expression language, before we inserted the 1.0.4 branch; within this, the Expression language spec was in DEVELOPMENT phase).
well - development on the draft spec just continued. I wouldn’t want anyone to think we don’t have reliable release and versioning processes - we do, but we didn’t use them here. It may have also been the case that the specifications development lifecycle was not as obvious as it should be - for the record it is documented here.
yes - unfortunately, I didn’t know this. If I had, I would have suggested to the SEC to agree on a releasable version of this spec, so that implementations were connected to something stable.
We have much better communication these days, and I don’t think we’ll get into this situation again. We’ve put a fair bit of collective effort into getting this old Expressions spec stabilised retrospectively, so it indeed corresponds as closely as possible to these implementations.
It has been somewhat annoying for everyone, but I guess a good lesson on the importance of getting releasing right.
well, it’s not just some aesthetic preference - this older draft language was never finished, primarily because it contains some design problems. I had not performed a sufficiently full analysis to fix these at the time, so it remained in that state. The new version is:
- a) based on a much better analysis (including review of features in various other languages);
- b) has made much better use of current Antlr tools (4.9) which significantly improved a lot of details (more than I had expected I must admit);
- c) incorporates features that cover the semantics in use by the existing 4 separate expression languages in openEHR (ADL rules; AQL; Task Planning expressions; GDL2)
Well I and others have had a pretty careful look at doing that. The research project I worked at in Intermountain Healthcare doing advanced workflow looked at various existing languages including Java and TypeScript, and decided they did not do what was needed; they rolled their own expression language and had it running in a couple of weeks.
In the Task Planning project, Better went a step further and actually implemented a TypeScript execution container and converted (the relatively simple) expressions from string statements within a Task Plan into a TS internal representation for execution (I suspect via some JSON conversion that was then materialised by the container implementation). This was found to be seriously slow (probably fixable), but also missing some needed operators and features (not fixable). So they also decided to go native.
Implementing a language these days is relatively easy - that’s one reason there are so many programming languages around. The speed at which a language definition can be developed, tested and implemented is much higher than it used to be.
The approach I have taken in more recent times is based on a) a high quality meta-model aka ‘enhanced AST’ (= current version of BMM) and b) a full syntax implementation (= current LANG/Expression Language) in Antlr 4.x, to ensure that there is at least one working syntax. The meta-model provides the semantics, as well as the ability to serialise out to other syntaxes / languages.
This version of BMM and its associated (new) expression language is pretty generic and when it is completed (mainly the expression syntax part), will at least be a candidate for a common expression and decision language for openEHR. There is nothing stopping other development proposals from being created. At the end, the SEC will need to review and consider what to release for the wider community.
Others may have different opinions and approaches - these are all welcome from my point of view. We have the Specifications Editorial Committee to make determinations on a way forward based on what is available at any given time. THis is as it should be I think.
BTW: there is a call-out facility in the new BMM to enable a routine (i.e. set of statements / expressions) to be implemented using any language, which will take care of a) re-use of existing code and b) orgs that want to write expressions in current programming languages. This approach won’t be highly interoperable for decision logic, Task Planning, GDL3 etc, but it will be useful for other purposes.