quick answer for now - there are base patterns that should be used
across other projects like AQL
* here in the specifictions-BASE repository
<https://github.com/openEHR/specifications-BASE/tree/master/docs/odin>
* here in the specifications-AM repository
<https://github.com/openEHR/specifications-AM/tree/master/docs/ADL2>
look for the .g4 files. See particularly the 'base_patterns' one.
These files are currenty mixed in with the specs. I'll move them to a
more obvious place (so they stand alone, but also enable spec publishing).
If you just want to look at these grammars, go to the ADL2 and ODIN
specs (home page -> Specifications button ->...)
They are still being worked on, so don't trust them yet.
But do note that most terminal types in ADL apply to AQL, so we should
aim for a base_patterns and also odin_values grammars across openEHR.
- thomas
<https://github.com/openEHR/specifications-BASE/tree/master/docs/odin>On
24/08/2015 05:32, ANASTASIOU A. wrote:
Hello everyone
Please see further below regarding a few first steps towards "converting"
Chunlan's .g files in combination with Eiffel's lexer files to ANTLR's syntax. My main
motivation for doing this was to produce syntax diagrams for ADL and AQL but very early
on I realized that there was no point writing just the EBNF because I could be deriving
the ANTLR representation of the grammar and from that be able to produce a parser as well.
This was going well, until I realised that:
1) Certain definitions could be defined once and re-used in multiple places
2) Some definitions looked almost exactly the same but had different names
depending where they were applied
3) Some definitions would become obsolete / would not be able to co-exist
because of the way ANTLR expresses a grammar
4) Some definitions included conditional parsing with states and they were
becoming a bit indecipherable for me
5) Meantime, ADL 2.0 came along
I have specific examples for the above in a document were I kept notes as I was
going on which I intend to share. Part of it was also put at an earlier email
to Thomas...but this was long time ago by now.
The problem is that right now I am "on the road" (and have been for a few weeks
now), writing this just before I go into class at St. Andrews and cannot talk about this
to the level of detail I would love to :D
However, the key messages emerging from my experience are these:
A) I would appreciate help from people who wrote the .g and Eiffel YACC files
because these are not exactly documented. We need to know how some definitions
came to existence and more importantly, if we have two definitions that are
almost identical, which one do we keep?
B) !!!We need testing cases!!! for each definition. This became essential as I
was going on and had to jump back and forth changing definitions. Of course,
when you do that, it has an impact on every definition uses the modified part.
My tool of preference was Python. The Python ANTLR target code generation was
recently reworked and it works almost exactly as its JAVA counterpart. It could
be used to create quick test code through a makefile or something.
C) I found it easier to work bottom-up. So, if we were to quickly get
elementary data types / definitions out of the way relatively quickly then the
real work can start on parts of the grammar that are not exactly
straightforward :)
Repositories at:
A first step for AQL can be found at:
https://bitbucket.org/aanastasiou/openehr-aql-syntax
Some progress has also been made towards EBNF for ADL at:
https://github.com/aanastasiou/adl_ebnf
I hope this helps, had a quick look at the MedInfo stuff and it looks really
exciting!
All the best
Athanasios Anastasiou
________________________________________
From: openEHR-technical [openehr-technical-boun...@lists.openehr.org] on behalf
of Thomas Beale [thomas.be...@oceaninformatics.com]
Sent: 03 July 2015 11:10
To: For openEHR technical discussions; For openEHR clinical discussions
Subject: Re: openEHR specifications - the future is Asciidoctor + MagicDraw?
Athanasios,
excellent suggestion. I haven't even looked at building in syntax diagrams right now,
but your timing is perfect - I was contemplating how to put the ADL grammar into the
new style spec in a nice way. Currently grammar is generated as an HTML page (as per
links on this wiki
page<https://openehr.atlassian.net/wiki/display/ADL/ADL+2+parser+resources>)
which is ok, but the source file is not in a re-usable form (it's a .y file
containing Eiffel code - but it would be the same problem with any language like Java
or C etc) and the lexer files are also not re-usable or easily publishable.
So we need to solve this in a way that makes the lexer and parser grammar files
primary, and then all other files based on them. All of this goes for AQL as
well.
Both ADL and AQL grammars can undoubtedly be improved - there is not only one
grammar for a language - so making changes for computability doesn't have to
break the language definition. I suspect that if we can get some optimal
grammars sorted out for Antlr, they will become the 'primary files' for these
languages in the ecosystem. Shinji is also after the same thing, and I think
has done some work on ADL grammar for Antlr.
So we need to do some work here, and your work looks like a good starting point.
As soon as we have a few more gremlins sorted out in the main toolchain, I'll
get myself up to speed on your and Shinji's work here and hopefully we can
create a solution which I think then really will make for a powerful
models+documentation+programming toolchain.
- thomas
On 03/07/2015 10:56, ANASTASIOU A. wrote:
Hello Thomas
This is looking really good and much more usable and lite than shifting through
PDFs.
Just a small suggestion / question.
Will it be possible to have (possibly automatically updated from a single
model) syntax diagrams for ADL / AQL?
A first step for AQL can be found at:
https://bitbucket.org/aanastasiou/openehr-aql-syntax
Some progress has also been made towards EBNF for ADL at:
https://github.com/aanastasiou/adl_ebnf
Both of these attempts to map the languages were made with the view of creating
syntax diagrams which are immensely useful when trying to provide the bigger
picture to people with minimal technical background.
The ADL EBNF hit some snags because of various differences in the definitions
across different files but in general, it is a straightforward task.
Happy to join forces if something like this is already underway.
--
Ocean Informatics <http://www.oceaninformatics.com/> *Thomas Beale
Chief Technology Officer*
+44 7792 403 613 Specification Program, /open/EHR
<http://www.openehr.org/>
Honorary Research Fellow, UCL <http://www.chime.ucl.ac.uk/>
Chartered IT Professional Fellow, BCS <http://www.bcs.org.uk/>
Health IT blog <http://wolandscat.net/category/health-informatics/>
View Thomas Beale's profile on LinkedIn
<http://uk.linkedin.com/in/thomasbeale>
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
