Hi! A little suggestion/thought (that might be of value also for CIMI-folks and others looking at "archetyping" using ADL and AOM and wondering if a specific language is needed).
*Limitations:* For efficient handling of RM (Reference Model) instances (patient data) flying back and forth between systems you'd probably want some binary format (protobuf <http://code.google.com/p/protobuf/>, thrift datatypes<http://thrift.apache.org/>, serialized Java objects or whatever), this is NOT what this suggestion is about. For development and debugging RM-instance exchange you may also want some fairly human-readable serialization that is supported by many platforms (Like JSON <http://www.json.org/>, YAML <http://www.yaml.org/>, XML or whatever) this is NOT what the suggestion is about either. Also note that the current suggestion only aims at looking for replacement of dADL not cADL. Also note that the AOM and XML serialisations of the AOM are not affected by this suggestion. *Background:* cADL (Constraint ADL) is a compact DSL<http://en.wikipedia.org/wiki/Domain-specific_language> that is aimed at defining constraints on an object model, while dADL (Data ADL) on the other hand is mainly a general object-graph serialization format. If I understand section 1.7.5 in the ADL 1.5 spec<http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/adl1.5.pdf>correctly, ADL 2.0 will allow the option to define *all *parts of an archetype (including what is now done in cADL) as a dADL serialization of the AOM<http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/aom1.5.pdf>(Archetype Object Model). Is that correct Tom? *Suggestion:* Investigate if YAML can replace or complement dADL as object-graph serialization format for archetypes. (Perhaps there is interest from people using an openEHR AOM implementation in a language that already has YAML serializers to make a quick experiment?) *Motivation:* - YAML parsers converting YAML documents to native object graphs already exist for a number of languages <http://www.yaml.org/> (C/C++, Ruby, Python, Java, Perl, C#/.NET, PHP, OCaml, Javascript, Actionscript, Haskell) so there would be less work creating and maintaining archetype parsers that turn archetype files into in-memory object graphs. (If you write an archetype authoring tool an need to validate archetypes, not just instantiate already validated archetypes, then the "Validity Rules" (such as the ones in blue under 4.3.1.1 in the AOM spec.) will of course still need to be implemented in software. - Having an archetype specific object-serialization language like dADL might make "archetyping" look more mysterious and suspect and might hide the fact that the semantics expressed in the AOM is the interesting thing that can be serialised in many different ways. - And (admittedly subjective) YAML lists and objects look slightly better and more readable than dADL. A notable exception is probably intervals/ranges that have a compact representation in dADL (see section 4.5.2 of the ADL 1.5 spec<http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/adl1.5.pdf>) but not natively in YAML. *Observations:* YAML is extensible, so data types for intervals etc can be added like in http://yaml.org/YAML_for_ruby.html#ranges, also see discussion at http://stackoverflow.com/questions/3337020/how-to-specify-ranges-in-yaml. A similar approach could be taken to dADLs "Plug-in Syntaxes" (see section 4.6<http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/adl1.5.pdf>) using YAML. A number of language-independent extra YAML datatypes (timestamp <http://yaml.org/type/timestamp.html>for example) are listed at http://yaml.org/type/index.html and you can define your own if you need more. It seems like specification 1.1 (http://yaml.org/spec/1.1/) is the most implemented, so any dADL comparisons should probably be done towards that version to be fair. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 P.s. Tom Beale and I sort of started a brief off-list discussion about YAML, here is now an attempt to get input from more people. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111122/a48d185a/attachment.html>
