Something IMPORTANT I have said before, and completely forgot due to other distractions:
There is a proposal (it's on the SPECPR issue tracker somewhere) to add a property to the LOCATABLE class called (say) sibling_id: INTEGER which would have the effect of unambiguously numbering sibings under a container attribute in the data. In XML data I would expect to make this an attribute, so the effect on paths would be be able to say cluster[at0009]/items[at0008, 2] as ADL short hand for cluster[@archetype_node_id='at0009']/items[@archetype_node_id='at0008', @sibling_id='2'] This is for next-gen openEHR obviously, so doesn't help Bert/Leo right now. anyone have thoughts on that? Note that the position() predicate should still work, which means it can't be in its short form as [...., 2], or else the sibling_id needs a different short syntax. Other note: sibling_id order will be the same regardless of re-ordering whereas the value of position() is whatever the physical position is. - thomas On 22/11/2013 08:33, Diego Bosc? wrote: > That's why I suggested this > /items[at0008]/value[1]/value = Jan > > As David said, /items[at0008][1] and /items[at0008][2] are referencing > the same node in ADL (at0008). > > In my opinion, if you want to access the leaf node for the value it > makes very little sense to try to reference the nearest object with > atXXXX. Or in other words, If you need to tell apart two siblings I > would put artificial identifiers in the nodes that don't have any. And > by the way, if you need to tell apart two sibling nodes because they > have different semantics (surname 1 & surname 2) you probably want to > put an identifier on those too in the first place.
