On 07/12/2011 11:29, Erik Sundvall wrote: > > Good old which ADL? Please go back in the thread and note the > difference between dADL and cADL in the reasoning, dADL is a > reinvention of the wheel (object tree serialization)
Erik, out of academic interest: was either YAML or JSON around in 2000, when I made a first version of dADL (I'm in a plane typing this, can't check)? If they were, I look silly ;-) If not... In any case, JSON is seriously semantically deficient for proper serialisation purposes and is in need of at least 2 basic enhancements to work correctly on any realistic data. I agree it is fairly readable, although why attribute names are in quotes is completely beyond me...I have not yet looked at YAML properly, but it looks like it probably does the job properly. > > Yes, a bit of diversity is good in order to best explore design space, > but duplicating work is a waste of time. > If we are allowed to discuss future-directed thoughts on this list > (without people getting too upset) that may also help us tune our > efforts. If we must implement first and then discuss it will be a lot > harder to avoid duplication of work. I don't actually think there is any harm in messing around with variations on serialisation - it's not hard to implement (XML being the hardest), but at some point I think a wiki page with a summary of real world requirements behind each variant would be useful. > > Are you referring to the CIMI-discusions or is it a general > observation about how the future usually is :-) > > Regarding CIMI I think it is valuable to try to look upon openEHR with > the eyes of newcomers. If there is unnecessary legacy in models or > formats that we don't easily see because we have gotten used to it, > then now is a good time to try reducing it while the amount of patient > data using openEHR is limited. It will be harder to change things > later. Getting the template formalism integrated with the AOM 1.5 was > great in this sense, and so is Tom's experimentation with RM 2.0 > constructs that may reduce the ITEM_STRUCTURE hierarchy. I have to do a bit more work to get the first proposal defined properly - there is a half done wiki page on that. Should have it fixed in a couple of days, then we can discuss. (I'm not online but if others find the page, feel free to put your own RM 2.0 variations on there somewhere). > > +/- infinity > Yay, I love flame wars :-) you can't win like that. Godel or someone showed that there are different sizes of infinity :) > > > The reason I started looking into both JSON and YAML is that they are > part of our current implementation (partly using JSON, Javascript etc) > (primarily for RM objects) in this process I happened to see that YAML > might do the job of dADL and that we then we could reuse > parser/serializer work of others (for many programming languages) > instead of maintaining dADL frameworks. I wanted to share this thought > at an early stage and I do appreciate that some have at least > responded with positive interest and curiosity. at some point I intend to finalise the ultimate dADL grammar and publish dADL as a standalone with at least C#, Java, Eiffel and possibly C/C++ fast & full parsers + serialisers. This is less work than you might think, and it would make dADL just as available as YAML. Well, ok it won't be in Erlang or Haskell for a while, but I doubt if that will make much difference. - thomas * * -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111207/01b62bc5/attachment.html>
