I too have no problem with this custom serialisation as I have a hand-coded serializer that does the job (I gave up on the auto-generated ones years ago).
However, I think we need to go back a step and get agreement from the community what the most important features of an XML serialization are: readability, size, auto-generation etc. Once we get some sort of ranking then we can score each implementation choice accordingly. I personally don't see the need to have consistently between different serialization formats, I think we should make the decisions that are best for the particular format. Having said that, I would be surprised if the logical features of the different formats would be different unless there intended use are dramatically different (i.e. the importance of auto-generation is likely to be the same for both JSON and XML). Heath > -----Original Message----- > From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- > bounces at openehr.org] On Behalf Of Andrew Patterson > Sent: Saturday, 12 November 2011 12:26 AM > To: For openEHR technical discussions > Subject: Re: occurrences and cardinality in ADL, XML, JSON > > On 11/11/2011 11:50 PM, Thomas Beale wrote: > > "occurrences": "1..*" > > well that's my opinion as well, and XML-ers always react badly! The > > 'proper' parser code for dealing with this form, used in the ADL > parser > > is (from the .y file): > > > Well I consider myself an XML-er and I don't see massive problems with > it, but > maybe I have become soft in my old age. > > My main argument would be that the XML at one point was almost a > straight serialization > of the object model, as supported by various XML data binding > libraries. So > XML -> AOM memory objects -> XML was all doable with very standard > binding libraries. > > BUT > > I was happy with status quo because I don't really care about the > size of the XML or how often elements are repeated or the fact that is > looks > ugly to people - if people want compressed data then they should use > fastinfoset > or exi, and then gzip and it'll compress beautifully. The > size/format/look > is a concern to others. > > BUT > > If I have lost the battle and if we are going to do customised > XML serializations then once you've taken it outside the > normal data binding by introducing "*" forms or even > 'properties' that aren't really properties but kind of quasi computed > fields > then you mind as well as give up on the pretence that the XML > serialization > will bind straight into an AOM compatible object model.. > in which case parsing "1..*" is not a problem > > Andrew > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
