Thanks Erik, Interesting to see the line up. Can't believe that XML wasn't the longest file in the list, that kills one of the arguments for JSON vs XML.
For someone that is not aware of YAML, are the white space significant. If so, this kinds of kills it for me, otherwise for a Human reader its fairly natural to read without lots of brackets of various kinds. Heath From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Erik Sundvall Sent: Friday, 2 December 2011 8:07 AM To: For openEHR technical discussions Subject: Re: Could YAML replace dADL as human readable AOM serialization format? Hi! Let the battle begin :-) see: http://www.imt.liu.se/~erisu/2011/AOM-beauty-contest.html On Tue, Nov 22, 2011 at 13:24, Thomas Beale <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? 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. 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 ...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? Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111202/92bf7a06/attachment.html>