My understanding so far was that protocol “exists” even it is completely unconstrained.
I.e. in data you can put in any ITEM_STRUCTURE into the protocol - whether protocol is constrained in the archetype or not. This is because protocol is an explicit optional ITEM_STRUCTURE in any CARE_ENTRY.
Then if an archetype in Revision A does not constrain the protocol at all, any data created against that archetype can thus have any kind of ITEM_STRUCTURE in its protocol data, not only ITEM_TREEs.
If the next revision of that archetype (Revision B) then constrains the protocol to only allow - say - ITEM_TREEs instead of all types of ITEM_STRUCTUREs, then Revision B is not guaranteed to be able to “read” data created using Revision A (because someone might have used an ITEM_TABLE for example).
Am I wrong in my understanding that this is the nature of a breaking change?
Now practically speaking it may well be that this is not relevant because it can be ascertained that this theoretically breaking change simply never has occurred in practice. This seems likely in this case and thus it may be useful as editors to be able to override the technical recommendation…but let’s first agree on whether this is a breaking change or not.
For reference:
protocol of Revision B:
protocol matches {
ITEM_TREE[at0035] matches { -- Item tree
items cardinality matches {0..*; unordered} matches {
allow_archetype CLUSTER[at0036] occurrences matches {0..*} matches { -- Extension
include
archetype_id/value matches {/.*/}
}
}
}
}