Details

    • Type: Problem Report
    • Status: In Progress
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: ADL2
    • Labels:
      None

      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.

        Attachments

          Issue links

            Activity

              People

              • Assignee:
                thomas.beale Thomas Beale
                Reporter:
                pieter.bos@nedap.com Pieter Bos
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated: