Shinji-san, thanks for the feedback.
On 25/04/2013 15:39, Shinji KOBAYASHI wrote: > Hi Thomas Beale, > > My comments: > 1) Page 33, A2 > JSON is no Java Simple Object Notation. JavaScript Object > Notation(http://www.json.org/) oops, getting old, memory going > 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? I wonder why not Base 128, since ODIN already assumed UTF-8 strings. The real question is: how to detect that we have some binary data? ODIN works on the idea that every leaf type is inferrable syntactically. In theory we could just do my_binary_data = <fsfbsb952hr32uewwbrfwev> where some characters will be from the non-printing characters in the 0-127 range. That wouldn't be a problem, but it could be a problem to distinguish from Integers, since some binary encoded data might come out to be my_binary_data = <952> So I think some other marker is needed in ODIN. Maybe something simple like my_binary_data = <#952#> > 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 guess you meant to include a link? I found this <http://www.rugson.org/techs/comparison/> at Rugson.org.. > I think one of the best feature of ODIN to compare these serialisation > techniques is that has strict type system, object oriented. > > I have to admit, I don't know how any data format without dynamic type markers can be used with real data... - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130425/a07cf4fe/attachment.html>
