Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expression language: Node IDs in paths in AOM, but not in RM: how to handle? #5

Open
pieterbos opened this issue Jul 5, 2016 · 3 comments

Comments

@pieterbos
Copy link

In archetypes, some nodes have node ids, that have no node id in the corresponding reference model object. This is tricky, because a valid path to an archetype node, converted to Xpath, is NOT a valid path to the corresponding reference model objects. For example, the context attribute of a Composition is an EVENT_CONTEXT. This does not have an archetype node id. But it always has one in the ADL/AOM. So if you write the path /context[id2], you can convert it to Xpath as /composition/context[@archetype_node_id = ‘id2’]. But this will result in an empty node set, because there is no matching attribute called archetype_node_id. Instead, you could just write /context, which works.

So, there are several options to address this in the specification, for example:

1.  Specify that paths to non-locatables should NOT have a [idx] predicate, even though the id in the archetype is present
2.  Specify that paths to non-locatables can have a [idx] predicate, but it should be ignored in implementations

Option 2 is a harder to implement, because you can no longer convert from Apath to Xpath without knowledge of the model. But as Apath expressions are not new, I’m thinking some other people will have an opinion on this :)

@wolandscat
Copy link
Member

In ADL2/AOM2 every object node has a code. E.g.:

    COMPOSITION[id1] matches {  -- Encounter
        category matches {
            DV_CODED_TEXT[id4] matches {
                defining_code matches {[at1]}
            }
        }
        context matches {
            EVENT_CONTEXT[id5] matches {
                other_context matches {
                    ITEM_TREE[id2] matches {
                        items matches {
                            allow_archetype CLUSTER[id3] matches {  -- Extension
                                include
                                    archetype_id/value matches {/.*/}
                            }
                        }
                    }
                }
            }
        }
    }

It is not quite correct to talk of RM objects 'having node ids' - node ids are only an artefact of archetypes, not the RM.
The way in which archetype paths can be reliably converted to RM data paths, e.g. in the form of an Xpath could be done by the following rule:

Only include the id-code as a path segment predicate if the id-code is defined in the terminology.

This is similar to your rule 1. above, but that rule is not quite reliable, since nothing stops a LOCATABLE type being used as the type of a single-valued attribute.

Currently runtime 'paths' don't have a specification of their own in openEHR, and are specified (sort of) in the Architecture Overview. We probably need to think about a standalone spec at some point.

@pieterbos
Copy link
Author

If a locatable is being used as the type of a single-valued attribute, shouldn't a path query to the RM object including an id-code should still map to that single valued attribute? If so, it's still quite reliable.

With your id is in terminology approach, if you map a single valued attribute to two different locatables, it looks like you can not define a rule that only works if one of the locatables is used instead of the other.

I'm not sure if that's a problem.

@wolandscat
Copy link
Member

If in an archetype a single-valued attribute has two alternative object nodes below it (e.g. OBSERVATION.protocol or COMPOSITION.context or similar) then those object nodes have to have id-codes and those id-codes have to be defined in the terminology.

Perhaps the best approach is simply to remove node-ids from a-path segments corresponding to single-valued attributes when converting an a-path to an Xpath?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants