On 21 Nov 2013, at 22:26, Thomas Beale <thomas.beale at oceaninformatics.com> wrote: > 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!).
Hey, that's great, so everything is in fact in perfect alignment :-) >> (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? Ahmmm...no, it's not really a requirement in and off itself, just existing use and existing implementation, and so with that the ball and chain of backward compatibility and software maintenance. >> 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. You know, if I were me I would do that too :-). In this instance the implementers perspective is actually easier than the spec/design perspective: liberal in acceptance is I guess to allow a bunch of different syntax variant and then always implement the same, sane, processing (i.e. predicate AND-ing), and from a backwards compatibility standpoint we'll probably keep producing [at0009][1]. That's basically what Bert's code does already (if it looks like an at-code, it's probably an at-code, if it looks like a number, it's probably an index, etc). I'm just continuing on with that pattern and tune it a bit during any adl-path-to-xpath assistance. It's good to be able to say that approach aligns with the expectations and intentations here! As for spec revision and such, it seems to me it could be a good idea to diverge a bit more explicitly from xpath (using wording such as "a lot like xpath" and "machine translatable into xpath", rather than "xpath compatible"), and allow the comma shortcut for indices, too, so you always end up with AND-ed predicates and can have one or more of [name,at-code,archetypeNodeId,archetypeId,index] perhaps even stating the shortcut form is considered the canonical one. That, or bigger changes to the point you end up with readable/writeable xpath and don't need shortcuts :) cheers, Leo -- This e-mail message is intended exclusively for the addressee(s). Please inform us immediately if you are not the addressee.
