pathAtItem in Compositions Context

Implementers (archive)
1

Sorry Sam, I was referring to the Java kernel implementation, not the specs.
Sam Heard wrote:

2

Hi Rodrigo,

Since EVENT_CONTEXT is not locatable, you don’t need to consider that object, instead only add the attribute name of the data you query under EVENT_CONTEXT to the path and it should work (e.g. /context/other_context[atXXXX]/).

Regards,

Mattias

2006/8/21, Rodrigo Filgueira <rfilgue@fing.edu.uy>:

3

Mattias, I was refering the actual available implementation.
Here is the code:

public Object itemAtPath(String path) {
        Object ret = super.itemAtPath(path);
        if (ret != null) {
            return ret;
        }
        String tmp = path;
        ret = checkAttribute(tmp, "content", content);
        if (ret == null) {
            throw new IllegalArgumentException("invalid path: " + path);
        }
        return ret;

    }

As you can see, the context attribute is not considered here, or are we missing something.
Mattias Forss wrote:

4

Rodrigo,

Sorry, I thought you had problems giving the correct path to the function.

You are right, the code doesn’t consider the context attribute because EventContext class is not Locatable. However there exists data that should be queryable in the EventContext class, for example setting and otherContext. The otherContext attribute is an ItemStructure which is Locatable and the itemAtPath implementation in the Composition class should probably consider the locatable attributes of the EventContext class.

Maybe Rong Chen has some comments on this…

Regards,

Mattias

2006/8/22, Rodrigo Filgueira <rfilgue@fing.edu.uy>:

5

Mattias Forss wrote:

Rodrigo,
Sorry, I thought you had problems giving the correct path to the function.
You are right, the code doesn't consider the context attribute because EventContext class is not Locatable. However there exists data that should be queryable in the EventContext class, for example setting and otherContext. The otherContext attribute is an ItemStructure which is Locatable and the itemAtPath implementation in the Composition class should probably consider the locatable attributes of the EventContext class.
Maybe Rong Chen has some comments on this...
Regards,
Mattias

just at a theoretical level, initially I made it a strict requirement that everything had to be LOCATABLE to be "path-able", but in the last few years, especially after learning how XPath works, I think this is a) unrealistic (it forces you to put node code where you don't need them) and b) unnecessary (you can have valid paths with no node codes; it is just when you have a container that you have to differentiate).

So, as design principle, think: Locatable is about adding semantic identification to information nodes, but is not required for pathing. Now you will realise that even for things that are not Locatable, you still want to implement the pathing functions (which will be trivial); you will see that you want an inheritance design more like:

Pathable
    +---Locatable

where everything (e.g. EventContext) inherits form Pathable or else Locatable (from which it gets the Pathable stuff). Now - these class names are not wonderful - if I had my time again, I would have done:

Locatable {class with path functions}
    +---Archetyped {adds in the archetype_node_id and name, and link to current Archetyped class - which wuld need to be renamed}

as you can imagine, we can't rename these now in the specs, so in my implementation I would do the first (Pathable, Locatable) even though the names are not brilliant. That's life in this game of standards-meets-software! Let's focus on the functionality not the names and that's where we will get the value. This pathing ability is key in openEHR, and enables it to do things that can't be done in any other system - semantic querying. We have this already working in Australia in the .Net implemtnation and it is very powerful.

I'll leave the Java to the specialists now;-)

- thomas

6

Thomas, good to know that pathable and locatable are not exactly the same.
It explains a lot.
In reference to the Java implementation we (by we I mean mostly Viterbo Rodriguez) have implemented what we needed.
It has not been tested yet but code is available to anyone who may want to check it out.

thanks again
Thomas Beale wrote: