Sibling order ordering rules contradict validity rule

Description

according to the ADL2-spec, it's legal to add a sibling ordering node with reference to a new node in the archetype, as long as it is present in the flat form of the current archetype
According to the AOM spec and I think also the ADL workbench code, it is only valid if it is present in the flat parent archetype.

That doesn't seem right. Which one of the two can be used?

I would say the ADL2 spec has the most logical explanation. If VSSM is correct, then it would be nice to have an example showing how to add two nodes after the same parent node id, and how those should be ordered in the output. Because that's not something that appears to be clear now.

sibling order ordering rules in ADL2 spec:

The rules for specifying ordering are as follows.

Ordering is only applicable to object nodes defined within a multiply-valued (i.e. container) attribute whose cardinality includes the ordered constraint;
Any before or after statement can refer to the node identifier of any sibling node known in the flat form of the archetype, i.e.:
the identifier of any redefined node;
the identifier of any new node;
the identifier of any inherited node that is not redefined amongst the sibling nodes.
If no ordering indications are given, redefined nodes should appear in the same position as the nodes they replace, while extension nodes should appear at the end.

Validity rule VSSM:
VSSM specialised archetype sibling order validity: the sibling order node id code used in a sibling marker in a specialised archetype must refer to a node found within the same container in the flat parent archetype.

Environment

None

Activity

Show:
Thomas Beale
November 21, 2017, 8:06 PM

One of the reasons the before and after is normally shown on its own line in ADL is to make it (a bit) clearer that these instructions set the anchor location for all the items that come after, until the next before / after is reached.

To get the effect you want, just write (as you already had):

after[id40]
ELEMENT[id0.41]
ELEMENT[id0.42]

I'll make this clearer in the spec.

Pieter Bos
November 24, 2017, 11:11 AM

Thanks, that makes sense. I think it's good to change it - the current ADL 2 spec says about before and after 'These keywords are followed by a node identifier reference, and act to modify the node definition immediately following', which does not suggest they modify anything after that - and apparently, they should

I'll fix that in my validator and flattener.

One last question:
If i add a node, it's easy to see that it can always have a sibling order.
But if a node is redefined/specialized rather than a new node, is it valid for it to have a sibling order? So for example if i have a parent archetype containing the following:

items cardinality matches {*; ordered} matches {
ELEMENT[id2]
ELEMENT[id3]
}

And in the specialized archetype i do:

/items matches {
before[id2] ELEMENT[id3.1]
}

Should that really change the ordering to id3.1, id2, or should it result in a validation error?

If it should give a validation error, it does not seem to be described in the specs.

Thomas Beale
November 24, 2017, 1:10 PM

THe current statement in ADL2 about this is:

  • If no sibling order markers are used, redefined nodes should appear in the same position as the nodes they replace, while extension nodes should appear at the end.

which I think is correct. So the above is fine, you can change the order of redefined nodes if you want.

In general, we don't want to make sibling order directives cause any/many fatal compilation errors, mainly warnings.

BTW I discovered that the ADL WB doesn't get it right in all cases either, particularly when there is a list of nodes and then a 'before' marker. I still need to fix this, so don't trust all AWB output.

Pieter Bos
November 25, 2017, 6:25 PM

There are some interesting edge cases, such as:

parent:
items matches {
ELEMENT[id2] occurrences matches {*}
ELEMENT[id3]
ELEMENT[id4]
}

specialized:
/items matches {
after[id3] ELEMENT[id0.5]
before[id2]
ELEMENT[id0.6]
ELEMENT[id3.1] occurrences matches {1}
ELEMENT[id0.7]
}

Which should be valid since all after and before node ids are in the parent container attribute. Should that in flat form be the following?

items matches {
ELEMENT[id0.6]
ELEMENT[id3.1] occurrences matches {1}
ELEMENT[id0.5]
ELEMENT[id0.7]
ELEMENT[id2]
ELEMENT[id4]
}

In that case, I think i can think of an algorithm that should work.

Seems like it also may have impact on when validating the order of RM data against an archetype - since you can reorder parent nodes in a specialized archetype, you have to be careful what you do and don't validate unless you validate against exactly the same level of specialization as the input data.

Pieter Bos
November 27, 2017, 11:55 AM
Edited

One minor thing still: In the case of redefinition with cloning, it looks like the redefined nodes should be placed directly after the original node. There's an example of that case in the spec, but I don't think 'redefined nodes should appear in the same position as the nodes they replace' captures this.

I have added test cases for sibling_order at https://github.com/openEHR/archie/pull/6/files.

Test archetypes at https://github.com/openEHR/archie/tree/correct_sibling_order/tools/src/test/resources/com/nedap/archie/flattener/siblingorder,

test at:
https://github.com/openEHR/archie/blob/correct_sibling_order/tools/src/test/java/com/nedap/archie/flattener/SiblingOrderFlattenerTest.java

I fixed the Archie flattener and validator - and the test succeeds.
I think these should be correct. Perhaps they could be an addition to the adl-reference testset?

Reporter

Pieter Bos

Labels

None

Components

Priority

Major
Configure