I totally agree with that, my argument was more about considering *only* syntax improvements without considering tooling and modeler's issues / challenges.
As a techie also I like simple and clear formalisms, but we can also read "machine code", so we might need a "simple enough" solution for syntax. without over-engineering it. Not saying this is the case, just mentioning this because is part of my mantra when I get too idealist with the things I create :) On Fri, May 19, 2017 at 2:01 PM, Thomas Beale <[email protected]> wrote: > Hi Pablo, > > for clinical modellers I completely agree. It is mostly technical people - > tool writers who work with the syntax form of things. But at the end of the > day, it is them who build the systems and who must understand every last > subtlety of the semantics of any of the languages we use - ADL, AQL, ODIN, > SNOMED constraint syntax, just as for the mainstream languages they use, > i.e. Java, C#, OWL, and so on. > > Determining a clean syntax for any part of a specification is part of > designing what that specification is about (for specifications that have a > syntax aspect). At the moment ADL, ODIN, BMM, and AQL are all cleartext > context-free syntaxes. Yes they tend to be read and written by tools in > operational circumstances, but to ignore the syntax is to ignore the > activities of learning, developing, testing, and debugging. > > Imagine trying to teach someone programming with no recourse to a > programming language, only in-memory compiler structures. > > Getting language right corresponds to obtaining clarity in a formalism. > Working on the tools is of course a big priority, but a different exercise > and (generally) people - it's a software development exercise. But they are > linked. I'll give you an example. To implement an archetype flattener > properly, as in the ADL Workbench, you need to know an algorithm for > flattening two archetypes. That means understanding the differential form > of archetypes. That means understanding paths, node ids and many other > elements of archetypes. This is all primarily described in the ADL2 spec > <http://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_specialisation> > because that is the easiest way to comprehend it. Some elements are > described in the AOM2 spec, but it's harder to see, since now we are > talking in-memory object structures defined by class models. > > So I remain convinced that languages have an important role to play in our > design, learning and understanding of things. Others may disagree ;) > > - thomas > > On 18/05/2017 16:22, Pablo Pazos wrote: > > I really believe we should be teaching using tools not reading syntax, > specially for clinical modelers. If we are doing that right now is because > tools lack usability, features and maturity. > > For techies, we like to look at the syntax because we need to parse and > process it. > > I'm not against improving the syntax, but since we don't have much > resources as a community, shouldn't we focus were the real problem is with > tools instead of patching the specs? > > Maybe clinical modelers can help software vendors on improving their tools > and to create new ones to help on the modeling process, and there are some > vendors creating such tools already but don't have input from the community. > > > > _______________________________________________ > openEHR-technical mailing list > [email protected] > http://lists.openehr.org/mailman/listinfo/openehr- > technical_lists.openehr.org > -- Ing. Pablo Pazos Gutiérrez Cel:(00598) 99 043 145 Skype: cabolabs <http://cabolabs.com/> http://www.cabolabs.com [email protected] Subscribe to our newsletter <http://eepurl.com/b_w_tj>
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
