On 01/12/2011 21:37, Erik Sundvall wrote: > Hi! > > Let the battle begin :-) see: > http://www.imt.liu.se/~erisu/2011/AOM-beauty-contest.html > <http://www.imt.liu.se/%7Eerisu/2011/AOM-beauty-contest.html>
nice page - that's quite fun to see them all pasted up there. My question is: what's the/your purpose for human readability. Is it: * education e.g. in some kind of class-room / training situation * debugging * self-learning * something else Just a question.... > > On Tue, Nov 22, 2011 at 13:24, Thomas Beale > <thomas.beale at oceaninformatics.com > <mailto:thomas.beale at oceaninformatics.com>> wrote: > > actually, ADL 2.0 as reported in this document is now obsolete. > The ADL 1.5 compiler already does this, and will use it as a fast > save/retrieve format. > > > Will cADL become optional or go away somehow? its not my intention. To be honest, I am not sure if a streaming cADL parser that knows it is parsing guranteed correct cADL might not be faster than the equivalent dADL parser for the archetype definition. But either way, cADL is a notation that really gives you a direct feel for the implicated semantics, so for understanding what you are looking at it has to be better. dADL / XML / JSON etc don't give you a direct picture, they give you a serialised object picture from which your brain has to infer an object structure (but admittedly this is unambiguous, so your brain will probably get it right). In my view 'proper syntax' is nicer for direct comprehension and therefore learning. > > One area where dADL beats JSON and YAML (I think) is its better > support for Xpath-like paths. > > > Why would that be different? I guess most path queries will run > on instantiated object trees rather than on documents and then there > is no difference - and if paths were run directly on documents, then > please explain why dADL would support them better. Looking at the JSON again, I might have to eat my words... I guess if the attribute names / hash tags are turned into Xpath predicates the implied set of paths has to be the same. > Plus its much more compact than JSON. > > > Much? Less noisy I would agree to though. > > Personally I find YAML hard to read because there are so many > syntax elements (triple '-', triple '.' etc) but that might just > be me. > > > Have a look at... > http://www.imt.liu.se/~erisu/2011/AOM-beauty-contest.html > <http://www.imt.liu.se/%7Eerisu/2011/AOM-beauty-contest.html> > ...again. > > The triple '-' and triple '.' are (mostly optional) start and end > markers of documents that make life easier when concatenating > streams/documents, see the YAML specification. > > Am I the only one that thinks YAML is more readable than dADL? when I get a moment I will add YAML to the serialiser club in the tool and we can then see if proper YAML is is or isn't better to read (I am assuming that it will be somewhat different from the inferred YAML you generated with that web tool). I think 'readability' is starting to come down to congitive and linguistic / semiotic issues, which is very interestinng. There may be no objective answer to this question; if there is it will be interesting to know what the criteria are. Nice work on the contest! - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111202/9a958ca7/attachment.html>
