Hi Thomas Beale, My comments: 1) Page 33, A2 JSON is no Java Simple Object Notation. JavaScript Object Notation(http://www.json.org/) 2) How to encode binary data? In order to serialise binary data as text format, it need to encoding system, such as Base64. What encoding system will you adopt to ODIN? 3) FYI: This presentation slides show the comparison of seven serialisation techniques. XML, JSON, Java binary serialize, Protocol Buffers, Apache Avro, Protostuff, and Rugson. I think one of the best feature of ODIN to compare these serialisation techniques is that has strict type system, object oriented.
Regards, Shinji 2013/4/25 Thomas Beale <thomas.beale at oceaninformatics.com>: > > I have updated the ADL and AOM 1.5 specifications to reflect recent > proposals for artefact identification. The main changes are that in the AOM, > the archetype id as we know it today is constructed from pieces of > meta-data, of which the version identifier is one. > > A more interesting change for most people may be that I have now removed the > 'dADL' part of the ADL specification and given it a new name and its own > specification. For those who don't know or remember, dADL is a pure, generic > object serialisation syntax - yes - another thing like JSON, etc. It's new > name is Object Data Instance Notation (ODIN) and the new spec can be found > here. You can see this specification is in a new 'syntaxes' group at the > bottom of the main table in the main specification baseline here. > > I have set up an ODIN project at the openEHR Github, here, with the idea > that we could collect the parsers and serialisers from various languages in > this project, or else point to them from here. > > Some may ask why we have ODIN (dADL), given that there is XML, JSON, YAML > and other syntaxes. There are reasons: when dADL was first invented (about > 2002), there was nothing except XML to use, and it is not a particularly > clean object serialisation syntax, nor realistically human readable. dADL > was designed to be properly object oriented, human readable and writable, to > have rich leaf data types, to support Xpath pathing, and to enable much > smaller texts than XML. > > Amazingly, dADL / ODIN still has stronger leaf data types, as well as > dynamic typing (a key feature lacking in JSON) and object identifiers. > > For anyone interested in putting together ODIN parsers/serialisers for the > various languages, please make yourself known, and let's discuss how to do > it. A survery of such syntaxes indicates that there is growing interest in > non-XML / post-XML data syntaxes (e.g. recent Dr Dobbs article), and I think > ODIN could have its place in the wider world. > > - thomas beale > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
