Does our XML schema somehow ensure that multiple elements of the same type have an order? For example: middle name has the cardinality 0..n - do we make sure the names are always in the correct order?
11073-10207 Revision: #251
PoCSpec: 10721 HF Device Content Gathering: #30
Our XML Schema assures the order of elements of different kinds, but not the order within the set of elements of the same kind is given.
For Containment Tree Elements like Channels, Metrics asf. we added a statement for clinical relevance. For your example regarding middle names, the order would need to be maintained by the provider resp. consumer.
To hock in this discussion: I suggest to define the order of AllowedValue elements to be fixed by the provider. I do not see any reason to force the order by and clinical relevance. However, I see the necessity of a fixed order at least in the following cases:
If there are active operation to switch through the list of values of the enum string (= list of allowed values), the order of this list has to be fix to ensure that n times triggered "next" operation and n times triggered "previous" operation will end at the same value; as well as starting from any particular value, m times triggering of any activate operation changing the value leads to the same result value.
Another dimension of the order of AllowedValue order and activate operations: Is the value list defined to be a "ring", i.e., triggering "next" operation at the last value will lead to the first value and vise versa?
Or is this simple a matter of device logic and runtime behavior? Semantically, I do not see any possibility to give any clue to the client what behavior it can expect.
see [opensdc:p11073-10107-content-gathering:#6]
Related
P11073-10107 Content Gathering: #6
As BICEPS defines a xsd:sequence of pm:AllowedValue the elements are ordered and every participant can rely on this unless descriptor changes. --> nothing to do
Add information to xc spec that a change in the order of the allowed values results in either a descriptor version change or a state version change depending on where the allowed values are used
Add a note R0034:
Diff:
Solved in [#251].
Related
11073-10207 Revision:
#251See https://github.com/ornet-ev/biceps/pull/236