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 On 11/19/2013 10:23 PM, Thomas Beale wrote: > On 19/11/2013 20:08, Bert Verhees wrote: >> Hi Alessandro, >> >> I think you propose this? >> >> /items[at0008,1]/value/value = Mark >> /items[at0009,2]/value/value = Rutte > > Either this or Bert's original (if it's legal Xpath) is correct, > assuming the data look something like (I just added the outer > <cluster> bit and header to make it work in a tool): > > <?xml version="1.0" encoding="UTF-8"?> > <cluster xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > archetype_node_id="openEHR-EHR-CLUSTER.bert.v1" > xmlns="http://schemas.openehr.org/v1";> > <items xsi:type="CLUSTER" archetype_node_id="at0007"> > <items xsi:type="ELEMENT" archetype_node_id="at0008"> > <value xsi:type="DV_TEXT"> > <value>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> > </items> > </cluster> > > I'm just messing around in Oxygen with some Xqueries and Xpaths. > > - thomas > > > > _______________________________________________ > 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/20131120/5ac202d6/attachment.html>
