On 21/11/2013 18:35, Leo Simons wrote:
> > (: from all the items, take the first one, then take all the ones with > node id at0009 :) > /*[1][@archetype_node_id=at0009] > > (: from all the items, take the first one iff it has node id at0009 :) > /*[@archetype_node_id=at0009 and position()=1] i.e., so two predicates in a row act like a pipeline of filters... > > Depending on the data you're xpathing, these may or may not have the same > result, since the construct [][] is a sub-select. I believe, looking at > everyone's answers, the intent of ADL paths is that most-precise third option > (AND of the predicates), which is also what we've implemented previously on > our SQL backend, and conceptually matches that proposal of > > [at0009,1] this was my intention when specifying it (years ago now!). > > (the , meaning AND I think), and that would make for an easy and unambiguous > ADL path --> xpath translation. > > But, those aren't the current rules, and with our xml backend, right now, we > have a not so easy ADL path --> xpath translation, because people want to > write > > [at0009][1] So I am unclear why you prefer to write this? Is there some system or customer requirement? > > which we dutifully turn into xpath > > [@archetype_node_id=at0009][1] > > which _seems_ the most spec-compatible behavior insofar as ADL paths are > precisely defined -- but that does not match what people mean. we could certainly extend the ADL path spec to allow this, it just needs to be specified as having different semantics from the above version. If I were you, I would work on the principle that paths of the form [@archetype_node_id=at0009][1] are legal (even if I don't quite understand why you want these particular paths) and have the semantics you have explained above. - thomas
