On 02/12/2011 01:35, Heath Frankel wrote:
>
> 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
>
*
*please everyone remember that the dADL, JSON and XML generated from AWB 
all currently use the stringified expression of cardinality / 
occurrences / existence. Now, these are usually the most numerous 
constraints in an archetype and if expressed in the orthodox way, take 
up 6 lines of text, hence the giant files (e.g. AOM 1.4 based XML we 
currently use) - and thus the much reduced files you see on Erik's page, 
because we are using ADL 1.5 flavoured serialisations not the ADL 1.4 one.

Now, I think we should probably go with the stringified form in all of 
these formalisms. The cost of doing this is a small micro-parser, but it 
is the same microparser for everyone, which seems attractive to me.

The alternative that Erik mentioned was more native, but still efficient 
interval expressions, e.g. dADL has it built in (0..* is |>=0| in dADL), 
and YAML and JSON could probably be persuaded to make some sort of array 
of integer-like things be used. XML still doesn't have any such support. 
In theory this approach would be the best if each syntax supported it 
properly, but XML doesn't at all, and the others don't support Intervals 
with unbounded upper limit (i.e. the '*' in '0..*'). *
*
But Erik's exercise certainly proved that efficient representation of 
the humble Interval <Integer> is actually worthwhile. (Once again thanks 
for that page, its quite a good way to get a good feel for these 
syntaxes very quickly).*
*
- thomas
*
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111202/2faed937/attachment.html>

Reply via email to