I think previously I had indicated I had no problem with the stringified interval approach in XML, but I am reverting my thinking on this and feel that it would be counter intuitive for those who what to use the XML schemas for code generation purposes. I think in this case the computable requirement outweighs the human readable requirement. I think we can come up with a much more concise representation of these intervals without compromising the computable requirement, something similar to XML schema maxOccurs/minOccurs.
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/20111205/e752fdcd/attachment.html>
