Hi Pablo, My problem was not what you've described. I thought there was a gap in the spec that let data exist without a node Id when there is need for one. That was not the case.
As long as the archetypeNodeId is in the data, there is no need for a rule that enforces node id based path usage, because node Id is there to find out if necessary. (this is not the easiest thing to communicate over e-mail :) ) All the best Seref On Tue, Aug 14, 2012 at 9:42 PM, pablo pazos <pazospablo at hotmail.com> wrote: > 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 <http://twitter.com/ppazos> > > ------------------------------ > Date: Tue, 14 Aug 2012 19:44:53 +0100 > > From: thomas.beale at oceaninformatics.com > 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 > > _______________________________________________ > 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/ffc235d9/attachment.html>
