# Index in array's in ADL **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2013-11-19 12:45 UTC **Views:** 15 **Replies:** 38 **URL:** https://discourse.openehr.org/t/index-in-arrays-in-adl/13136 --- ## Post #1 by @system Hi all, I had following interesting discussion\. Suppose we have a cluster containing name of a person\. There is a field called firstname, and a field called lastname\. The problem is concerning the ADL\-path, what should be used\. This is a part of the archetype: CLUSTER\[at0007\] occurrences matches \{0\.\.1\} matches \{ \-\- voornamen                         items cardinality matches \{0\.\.\*; ordered\} matches \{                             ELEMENT\[at0008\] occurrences matches \{0\.\.\*\} matches \{ \-\- firstname                                 value matches \{                                     DV\_TEXT matches \{\*\}                                 \}                             \}                             ELEMENT\[at0009\] occurrences matches \{0\.\.1\} matches \{ \-\- lastname                                 value matches \{                                     DV\_TEXT matches \{\*\}                                 \}                             \}                         \} This is a hypothecical example, only to explain: Because at0008 has upper\-occurrences of more then 1 \( a person can have more then one firstnames\) And at0009 has upper\-occurrences of 1 \(people only have one last\-name \(in this hypothetical country\)\) If we want to express data in a path/value combination, what would be the best solution?    /items\[at0008\]\[1\]/value/value = Jan    /items\[at0008\]\[2\]/value/value = Peter    /items\[at0009\]/value/value = Balkenende    /items\[at0008\]\[1\]/value/value = Jan    /items\[at0008\]\[2\]/value/value = Peter    /items\[at0009\]\[1\]/value/value = Balkenende    /items\[at0008\]\[1\]/value/value = Jan    /items\[at0008\]\[2\]/value/value = Peter    /items\[at0009\]\[3\]/value/value = Balkenende Or would another solution be better? Thanks in advance for suggestions\. Kind regards Bert Verhees --- ## Post #2 by @yampeku Hi Bert, Personally I would use:   /items\[at0008\]/value\[1\]/value = Jan   /items\[at0008\]/value\[2\]/value = Peter   /items\[at0009\]/value/value = Balkenende Regards --- ## Post #3 by @pablo Agree with Diego, I would use indexes only for repeatable data. --- ## Post #4 by @Alessandro_Torrisi i would say /items[at0008,1]/value/value = Mark /items[at0008,2]/value/value = Rutte Alessandro --- ## Post #5 by @system Hi Alessandro, I think you propose this?   /items\[at0008,1\]/value/value = Mark   /items\[at0009,2\]/value/value = Rutte regards Bert Verhees Alessandro Torrisi schreef op 19\-11\-2013 20:19: --- ## Post #6 by @thomas.beale Either this or Bert's original (if it's legal Xpath) is correct, assuming the data look something like (I just added the outer bit and header to make it work in a tool): Jan Peter Balkenende I'm just messing around in Oxygen with some Xqueries and Xpaths. - thomas --- ## Post #7 by @Alessandro_Torrisi Bert, I was not clear, but this is is my suggestion /items[at0008,1]/value/value = Jan /items[at0008,2]/value/value = Peter /items[at0009]/value/value = Balkenende Alessandro --- ## Post #8 by @ian.mcnicoll Hi Allessandro, I like that\. It is neat and fits well with the existing specialisation dot notation\. It is something we might be able to make use of in templates as well\. Ian --- ## Post #9 by @system Hi all, Thank you very much for your response\. First I want to respond to this one\. Because there is also an XML issue\. It is not that I want to be unfriendly, but, this also needs to be discusses\. I assume, the OpenEHR\-XSD's are inspiration for this OpenEHR XML\. I write, inspiration, because it is not possible to use the XSD's for definition of XML\-instances\. I filed a call yesterday on JIRA for that: http://www.openehr.org/issues/browse/SPECPR-93 But now I see another problem\. If the "element" thing \(see JIRA\) was repaired in the XSD's, then still, in my opinion, it would not be possible to come to following XML\-fragment\. This is also a point that needs to be discussed\. IMHO, it would look like this: <?xml version="1\.0" encoding="UTF\-8"?> <cluster xmlns="http://schemas.openehr.org/v1"   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"   xsi:schemaLocation="http://schemas.openehr.org/v1 file:Structure\.xsd" archetype\_node\_id="openEHR\-EHR\-CLUSTER\.bert\.v1">          <items archetype\_node\_id="at0008">              <value>                  <value>Jan</value>              </value>          </items>          <items archetype\_node\_id="at0008">              <value>                  <value>Peter</value>              </value>          </items>          <items archetype\_node\_id="at0009">              <value>                  <value>Balkenende</value>              </value>          </items> </cluster> > I'm just messing around in Oxygen with some XSD's\. Me to ;\) But for the rest, I like the XML\-approach of defining paths, although, I am not sure about the XPath\-style, because I think that XPath is a query\-language\. That is one of the reasons why I started this discussion\. I happen to be in a renovation of some kernel\-internals, and I want the path's used to have some kind of legitimacy\. That is why I ask you to help me thinking about it\. Thanks, Bert --- ## Post #10 by @system Hi, The idea below was by Leo Simons in a private discussion, I mention also my remarks on it, to ask your opinions on this If we would have produced this XML from a dataset: <?xml version="1\.0" encoding="UTF\-8"?> <cluster xmlns="http://schemas.openehr.org/v1"   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"   xsi:schemaLocation="http://schemas.openehr.org/v1 file:Structure\.xsd" archetype\_node\_id="openEHR\-EHR\-CLUSTER\.bert\.v1">          <items archetype\_node\_id="at0008">              <value>                  <value xsi:type="DV\_TEXT">Jan</value>              </value>          </items>          <items xsi:type="ELEMENT" archetype\_node\_id="at0008">              <value xsi:type="DV\_TEXT">                  <value>Peter</value>              </value>          </items>          <items xsi:type="ELEMENT" archetype\_node\_id="at0009">              <value xsi:type="DV\_TEXT">                  <value>Balkenende</value>              </value>          </items> </cluster> The XPaths would look like: /cluster\[@archetype\_id='openEHR\-EHR\-CLUSTER\.bert\.v1' and @archetype\_node\_id='at0007'\]/items\[position\(\)=1 and @archetype\_node\_id='at0008'\]/value/value=Jan /cluster\[@archetype\_id='openEHR\-EHR\-CLUSTER\.bert\.v1' and @archetype\_node\_id='at0007'\]/items\[position\(\)=2 and @archetype\_node\_id='at0008'\]/value/value=Peter /cluster\[@archetype\_id='openEHR\-EHR\-CLUSTER\.bert\.v1' and @archetype\_node\_id='at0007'\]/items\[position\(\)=3 and @archetype\_node\_id='at0009'\]/value/value=Balkenende As you can see, I use the attribute archetype\_id, which is not in the specifications, but also I filed an JIRA for that http://www.openehr.org/issues/browse/SPECPR-92 But apart from that There are a few things that I don't like about this XPath notation for non\-query\-purpose\. First is the connecting operator "and" \(in position\(\)=1 and @archetype\_node\_id='at0008'\), it is meaningless, because I am not defining a logical condition\. The second thing is that items which are different \(in archetype\_node\_id\) also gets an index\-notation, following on the previous\. \(3 in this case\) The problem is that the feel\-weight \(like we build up over the years\) of elements with a different archetype\_node\_id is that it is a completely different element, although belonging to the same items\-list in code\. In the OpenEHR culture, we tend to omit an index\-notation, when the element is unique because of its archetype\_node\_id, but I wonder, is that the right thing to do? So I wonder, is X Path\-compatibility the right answer to this? So, summarizing three problems with xPath: \- the logical operator "and" while it is not a query \- the index still counting while different archetype\_node\_id \- there was one more, but it slipped from my mind, and I have to leave right now in a hurry\. Maybe not following xPath\-like path\-notation is a better idea? I will reply later to the other mails regarding this Thank you all very much Bert --- ## Post #11 by @thomas.beale For reference, in terms of 'real XML' here is an example of a coded term:                          <items xsi:type="ELEMENT" archetype\_node\_id="at0001">                              <name> <value>Episodicity</value>                              </name>                              <value xsi:type="DV\_CODED\_TEXT">                                  <value>First ever</value>                                  <mappings>                                      <match>=</match>                                      <target>                                          <terminology\_id> <value>SNOMED\-CT</value>                                          </terminology\_id> <code\_string>255217005</code\_string>                                      </target>                                  </mappings>                                  <defining\_code>                                      <terminology\_id> <value>local</value>                                      </terminology\_id> <code\_string>at0033</code\_string>                                  </defining\_code>                              </value>                          </items> Of course he XSD for the next release of openEHR could be much more efficient than that\. But that's what we use today\. \- thomas --- ## Post #12 by @thomas.beale in terms of this particular issue, the current XSDs were designed for only a few 'top-level' document root objects, such as Composition, Party and so on. I agree that it needs to be more flexible. But I don't think that affects the particular question of paths we are discussing here (but thanks for recording the issue - that will definitely get addressed). You are right that my little example is not technical valid in this way - I just wrapped the core XML so as to make Oxygen happier ;-) well again, this is 'illegally' wrapping a small fragment to make it standalone. And the at0007 level is missing... as for the paths, it depends on your starting point in the hierarchy as well. I like Alessandro's solution, if it is legal. From your other post you had: /cluster[@archetype_id='openEHR-EHR-CLUSTER.bert.v1' and @archetype_node_id='at0007']/items[position()=1 and @archetype_node_id='at0008']/value/value=Jan /cluster[@archetype_id='openEHR-EHR-CLUSTER.bert.v1' and @archetype_node_id='at0007']/items[position()=2 and @archetype_node_id='at0008']/value/value=Peter /cluster[@archetype_id='openEHR-EHR-CLUSTER.bert.v1' and @archetype_node_id='at0007']/items[position()=3 and @archetype_node_id='at0009']/value/value=Balkenende if I rewrite that in openEHR-shortened form, so we can read it : /cluster[at0007]/items[at0008 and position()=1]/value/value='Jan' /cluster[at0007]/items[at0008 and position()=2]/value/value='Peter' /cluster[at0007]/items[at0009 and [position()=3]/value/value='Balkenende' It would be a small step to allow: /cluster[at0007]/items[at0008, 1]/value/value='Jan' /cluster[at0007]/items[at0008, 2]/value/value='Peter' /cluster[at0007]/items[at0009, 3]/value/value='Balkenende' BTW some existing information on paths is inn the , paths and locator chapter. - thomas --- ## Post #13 by @yampeku Take into account that \[position\(\)=1\] is equivalent to \[1\] in XPath\. In fact, another thing worth noticing is that if you can assure unique atCodes you only need to put last one\. Using both XPath look like this /cluster\[@archetype\_id='openEHR\-EHR\-CLUSTER\.bert\.v1'\]/items\[@archetype\_node\_id='at0008'\]/value\[1\]/value=Jan /cluster\[@archetype\_id='openEHR\-EHR\-CLUSTER\.bert\.v1'\]/items\[@archetype\_node\_id='at0008'\]/value\[2\]/value=Peter /cluster\[@archetype\_id='openEHR\-EHR\-CLUSTER\.bert\.v1'\]/items\[@archetype\_node\_id='at0009'\]/value/value=Balkenende By the way, I see these like an argument for using atCodes in all object nodes\. I don't think anyone would argue that using atCodes is less clear than using \[1\],\[2\], and \[3\] \(being \[3\] in a completely different branch\) --- ## Post #14 by @system This one indicates one items\[at0008\]\-element with to value\-elements in it\. I don't think that is right\. It should be /cluster\[@archetype\_id='openEHR\-EHR\-CLUSTER\.bert\.v1'\]/items\[@archetype\_node\_id='at0008'\]\[1\]/value/value=Jan /cluster\[@archetype\_id='openEHR\-EHR\-CLUSTER\.bert\.v1'\]/items\[@archetype\_node\_id='at0008'\]\[2\]/value/value=Peter /cluster\[@archetype\_id='openEHR\-EHR\-CLUSTER\.bert\.v1'\]/items\[@archetype\_node\_id='at0009'\]/value/value=Balkenende regards Bert --- ## Post #15 by @yampeku It is right in XPath, maybe is less intuitive, but I would say these are even less intuitive and still work /cluster\[@archetype\_id='openEHR\-EHR\-CLUSTER\.bert\.v1'\]/items/value\[3\]/value=Balkenende /cluster\[@archetype\_id='openEHR\-EHR\-CLUSTER\.bert\.v1'\]/items\[3\]/value/value=Balkenende I think we should decide why is this for: Is this for ADL paths? then use ADL path syntax\. Is this for XML query? then use XPath No need to reinvent the wheel --- ## Post #16 by @system I am thinking the same, I was just wondering if there was something which could be optimized. But first, let me describe to get to my explanation. In XML-land, there is only a path-notation which serves for queries, that is xPath. That is why I think it is not right for expressing paths. In ADL-land, there is a path-notation which can serve paths-expressions, and queries, like is described in the Architecture-Overview document. There is room for erroneous ambiguities in path-definitions, because of doubled information, and also there are inconsistencies in ADL path-syntax and there are unnecessary restrictions. And an archetype is a data-structure description, it should not have data in it. To define the position of a leafnode, no data or leafnode-constraints should be used. One could compare it with XSD, which is the same for XML. When you have a data-value, how do you define to which node it belongs, and were that node resides in a complex data-construct. This is described at page 66 at the Overview-document. But how to use the first node is not specified. Maybe it is somewhere else. So this should be, in ADL-path-notation: So the lower-case rm-type is placed, before placing the archetype_id, while the archetype_id has the rm_type information, even already in his Id. A chance for ambiguity! Never demand for information to be written twice! And also inconsistent, because in case of an archetypeslot, instead of the lower-case rm-type, the attribute name which contains the slot is used. Like this were the attribute "data" has the archetypeid "an.another.archetype.id" Also this is not nice, because it restricts, and does not tell us what happens. It restricts, because it leaves no room for an archetype_node_id, which can be on the attribute data (without archetype_node_id it is impossible to refer to it in the ontology) So following construct would emerge, if wanting data to refer to ontology : eventually with an index in it or But this is impossible because of removal of the attribute archetype_id, and having to put the archetype_id in the attribute archetype_node_id. This is an unnecessary restriction. ------------------------------------------ So, quite some time ago, I came to a way with less restrictions, less inconsistencies and less chances for erroneous ambiguities. -If there is an archetype_id, there is no need to mention the rm-type, because the information is in the archetype_id -If there is a slot, the attribute to which the slot is placed, is written as if there was another attribute to follow, just the same as always. -In this way there are no restrictions on also mentioning the archetype_node_id and eventually index. -An archetypeId in a path can always be recognized by its square brackets and no accompanying text (rmtype or attributename). So the example path will be The leading slash is not important and can be omitted. ------------------------------------------ I even had a short notation (I explain this just for fun) The curly brackets were needed to distinguish a archetype_node_id from an archetype_id. But this short path notation was never used much, not intuitive enough, I guess. So I forgot it. ------------------------------------------ So, why am I telling all this? First, I am not happy with the specs, how they define paths, I explained why. Second, I am not happy with my own solution, mostly because there is no consensus, it is a lonely adventure. And I was not happy with my index-notation, and when to use an index-notation. And in that part, you all did help me. I learned to better define and explain the way I go. When you look at an archetype, it has a parent-child construction. When to use an index-notation is when there are two similar children on one parent, so without index-notation, confusion could occur. Children are similar if they have the same attribute-name, same archetype_node_id, the same archetype_id. But I think that the notation with the comma is better, I am going to use that. It is not very important, it is just about defining how to define what the position of a datavalue/leafnode in the archetype-construct is. The drawback is that I still need ways to reconstruct paths, etc, for compatibility reasons. Thanks for your helping, and if some one wants to discuss it further, I am still open for that. It would be a good thing if the OpenEHR community would reconsider the ways paths are treated regards Bert Verhees --- ## Post #17 by @Leo_Simons Hey folks, > Take into account that \[position\(\)=1\] is equivalent to \[1\] in XPath\. Yup\! The only reason to have the discussion is the difference, in xpath, between   \(: from the items with node id at0009, take the first one :\)   /\*\[@archetype\_node\_id=at0009\]\[1\]   \(: 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\] 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\] \(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\] 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\. Hence, confusion, anger, suffering, and me asking Bert and Bert asking you :\) regards, Leo PS: Jan Peter Balkende is prof\. mr\. dr\. dr\.h\.c\. mult\. Jan \_\_Pieter\_\_ Balkende, Jan Peter is his roepnaam which should probably be kept as one string\.\.\.\.\. --- ## Post #18 by @thomas.beale firstly, the statement about atcodes above is right \- we only need to do this \[1\] \[2\] business when there are multiple instances of the same at\-code\. In the above, the \[1\] and \[2\] selectors aren't to select different values from under an ELEMENT \(which is what the at0008 selects\), so I would have expected them where Bert put them\. But I'm not sure if the above is wrong either\. Someone should see what Saxon makes of the above compared to Bert or Alessando's version\. I'll try on the weekend if noone else gets round to it before then\.\.\. \- thomas --- ## Post #19 by @thomas.beale > It is right in XPath, maybe is less intuitive, but I would say these > are even less intuitive and still work > /cluster\[@archetype\_id='openEHR\-EHR\-CLUSTER\.bert\.v1'\]/items/value\[3\]/value=Balkenende > /cluster\[@archetype\_id='openEHR\-EHR\-CLUSTER\.bert\.v1'\]/items\[3\]/value/value=Balkenende Diego, do you mean you tested this? Could you provide the XML source content you did this on? > I think we should decide why is this for: > > Is this for ADL paths? then use ADL path syntax\. > Is this for XML query? then use XPath well what we want I believe, is for the ADL paths to be easily mappable \(i\.e\. simple algorithm\) to convert to the correct Xpaths\. I'm not yet convinced we have the answers right here\. Happy to be corrected though\. \- thomas --- ## Post #20 by @thomas.beale > >    \(: 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 --- ## Post #21 by @system > > > (: 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... Exactly, that is my objection, the example is not a path/location to a leafnode, but it is a filter, the keyword "and" can be replaced by "or" and then something different comes out. Very useful in xPath, but not in leafnode-location-indicator. So as location-indicator the keyword "and" is useless, because it cannot be replaced. And that is my second objection, the use of a meaningless/useless keyword. The purpose of the path is solely to indicate to which leafnode in an archetype a DataValue belongs. > > [at0009,1] Exactly, a comma will do, however I currently do not support this, but I use an index in square brackets [1], but I am going to change that. So I see, for me, no reason to further discuss this, but I hope others will, and I am very interested in the outcome. regards, Bert --- ## Post #22 by @system > > > Take into account that [position()=1] is equivalent to [1] in XPath. > > In fact, another thing worth noticing is that if you can assure unique > > atCodes you only need to put last one. Using both XPath look like this > > > > /cluster[@archetype_id='openEHR-EHR-CLUSTER.bert.v1']/items[@archetype_node_id='at0008']/value[1]/value=Jan > > /cluster[@archetype_id='openEHR-EHR-CLUSTER.bert.v1']/items[@archetype_node_id='at0008']/value[2]/value=Peter > > /cluster[@archetype_id='openEHR-EHR-CLUSTER.bert.v1']/items[@archetype_node_id='at0009']/value/value=Balkenende > > firstly, the statement about atcodes above is right - we only need to do this [1] [2] business when there are multiple instances of the same at-code. I agree, since we are not writing XML or xPath, but ADL paths, we can honour our own rules. In XML the archetype_node_id is just an attribute, and when you read about XML Schema, you see that the element name is very important, and attributes are often ignored in these element rules. So in XML formalism it is understandable that elements with different archetype_node_id (an attribute) can fit in the same list-array, and having the same counter- But because we need to honour our own rules in which the archetype_node_id is very important, and two elements with same names but different archetype_node_ids cannot be in the same list-array. Bert --- ## Post #23 by @system > > > It is right in XPath, maybe is less intuitive, but I would say these > > are even less intuitive and still work > > /cluster[@archetype_id='openEHR-EHR-CLUSTER.bert.v1']/items/value[3]/value=Balkenende > > /cluster[@archetype_id='openEHR-EHR-CLUSTER.bert.v1']/items[3]/value/value=Balkenende > > Diego, > do you mean you tested this? Could you provide the XML source content you did this on? There is only one way to read this. In the first line in items is a list-array with at least three cells. In the second line is an array of items-cells in cluster. Line one is illegal in the OpenEhr RM, but of couse one can write an RM in which it is possible, so, as ADL it is legal. > > I think we should decide why is this for: > > > > Is this for ADL paths? then use ADL path syntax. > > Is this for XML query? then use XPath > > well what we want I believe, is for the ADL paths to be easily mappable (i.e. simple algorithm) to convert to the correct Xpaths. I'm not yet convinced we have the answers right here. Happy to be corrected though. A programmer does not look for easy mapping, in fact, how more difficult the mapping, there will be opportunity to make money. But seriously, easy mapping, difficult mapping, who cares, there needs to be written code, one day, or one week, it will last for ever. So easy mappable in syntax or difficult, it is just code and not very interesting. But the mapping must be possible. Don't try to map ADL-archetypes to XML Schema, that is not possible. That is not easy or difficult, but impossible. But from ADL paths/queries to xPath is very well possible, and only a bit difficult. IMHO there is no reason to change ADL path to kinda xPath. Bert --- ## Post #24 by @Leo_Simons >>   \(: 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 --- ## Post #25 by @system I'm still struggling to understand the reason of all this discussion\. In the previous example, an instance data value \(not DataValue\) belong to the node \[at0009\], that's all even if that node has multiple occurrences\. ADL paths are used to reference object nodes within an archetype, not instances, and in an archetype every node type is unique\. A different thing is if you are talking about ODIN/dADL paths\. --- ## Post #26 by @system The word "probably" indicates that it is not safe\. No programming\-language/compiler allow a name of something to start with a number, and certainly not, be a number\. So it is very common practice to guess if a combination of characters is a number, and if it is, it cannot be a name\. Thus, the probability if something is an index of an array \(always a number\) or a name/atcode is 100%\. Bert \(PS: The comma to add an index inside the square brackets of an atcode only works when there is an atcode\. So this is not always the case\. The square\-bracket notation of an index always is possible\.\) --- ## Post #27 by @system That is the case\. The discussion is about how to indicate to which leafnode in an archetype datavalues belong\. Every leafnode has an unique path towards it\. In fact, the starting of the discussion was that some kernel\-developers/users use path/value combinations, and not object\-representing notations to handle datavalues in combination with archetype definitions\. Bert --- ## Post #28 by @system I should not try to write English, at midnight\. Excuse me ;\) Bert --- ## Post #29 by @yampeku 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. --- ## Post #30 by @thomas.beale well... we sort of are here. I guess the point is that it makes no sense if the runtime paths for archetyped data are not completely consistent with the pure (design-time) archetype paths, i.e. a clean superset of syntax. - thomas --- ## Post #31 by @yampeku Just tested it with the xml you provided. The second one works, first one doesn't. It's weird because in the sample data I created they did in fact work. I generated it modifying another instance you put on this thread. --- ## Post #32 by @thomas.beale 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 --- ## Post #33 by @thomas.beale > > Something IMPORTANT I have said before, and completely forgot due to other distractions: 'should' have said before\! --- ## Post #34 by @system I am not sure about this, sibling\_id is the array\-index, when I understand\. What happens in case a dataset changes, for example an item is removed from a cluster, in that case all the other datasets should need revisiting to have this property changed\. For my idea, the array\-index is volatile and calculated at the moment of need\. Bert --- ## Post #35 by @yampeku Or attribute is unordered --- ## Post #36 by @thomas.beale the intention is that it would only ever be calculated once, at creation time\. So it would be immutable in fact\. That's the current design idea \- this isn't documented anywhere properly, and others may have better ideas, so feel free to suggest them\. \- thomas --- ## Post #37 by @Colin_Sutton Bert Verhees said> Or would another solution be better? I suggest: /items\[at0008\]/value/value = Jan Peter /items\[at0009\]/value/value = Balkenende or CLUSTER\[at0007\] occurrences matches \{0\.\.1\} matches \{                             ELEMENT\[at0008\] occurrences matches \{0\.\.\*\} matches \{ \-\- givenname                                 value matches \{                                     DV\_TEXT matches \{\*\}                                 \}                             \}                             ELEMENT\[at0009\] occurrences matches \{0\.\.\*\} matches \{ \-\- middlenames                                 value matches \{                                     DV\_TEXT matches \{\*\}                                 \}                             \}                             ELEMENT\[at0010\] occurrences matches \{0\.\.1\} matches \{ \-\- familyname                                 value matches \{                                     DV\_TEXT matches \{\*\}                                 \}                             \}                         \} then /items\[at0008\]/value/value = Jan /items\[at0009\]/value/value = Peter van Wat /items\[at0010\]/value/value = Balkenende i\.e\. don't use indexes \- especially where they contradict the meaning: \* How can you have two 'first' names? \* Family names come first in some asian languages\. Regards, Colin --- ## Post #38 by @Joe_Griffiths Thomas how do I get George's email off this list as I am getting all his emails? Regards and thanks, Joe Griffiths 0422 591 263 National Engagement Manager Joe\.Griffiths@oceaninformatics\.com                                                  www\.oceaninformatics\.com --- ## Post #39 by @system > i.e. don't use indexes - especially where they contradict the meaning: > * How can you have two 'first' names? > * Family names come first in some asian languages. Hi Colin, the discussion is about syntax, not semantics, and a given archetype is assumed. regards, Bert . --- **Canonical:** https://discourse.openehr.org/t/index-in-arrays-in-adl/13136 **Original content:** https://discourse.openehr.org/t/index-in-arrays-in-adl/13136