Hi Thomas, thanks for the answer. (now I see the problem of doublign the number of node ids) I understood the Seref's problem as a case that could not be decided automatically by a system, i.e. when to use and when not use the nodeID to query and to get the desired node. Re-reading your response, I believe this should be part of the specs as a rule: "...in this case, use the path items[at0004]/value[at0022]...", i.e. when you have alternatives but, in the data, one of them was choosen. What do you think? -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos
Date: Tue, 14 Aug 2012 19:44:53 +0100 From: [email protected] To: openehr-technical at lists.openehr.org Subject: Re: Should not node identifiers in runtime paths be mandatory? On 14/08/2012 18:46, pablo pazos wrote: Hi Thomas, Just thinking... Why not make node ID mandatory for all nodes? Since this will be handled by tools, I don't see the point of having to worry about if the node has an id or not: the tool just put some node ID on each node and us as developers use that fact to query and process data. It seems so much simple to have only one criteria, and we don't lose flexibility or expresiveness. Hi Pablo, the reasons we make it optional in cases where it is not needed: there are huge numbers of chains of leaf nodes near the periphery of most models, where every attribute has only a single object value (have a look at any ELEMENT node and below in any archetype); node_ids serve absolutely no purpose in these locations, but could easily double the number of ids in the model - and for each of these, some definition has to be invented. These 'junk' definitions would confuse translators who would never be sure what has to be translated and what not. it would increase the size of most paths used in real querying, because they nearly always have things like /value/value, or /value/magnitude on the end. So it actually creates problems without solving anything (for example, it has no impact at all on Seref's problem). The rules for knowing when they are needed are simple and published, and easy to implement, so it's no problem for tools. - thomas _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120814/ce4701d7/attachment.html>
