C2MS12 — Lack of Required Fields in Sub-elements

We have a number of cases where there is a listing of something, like Files in Product Message. Although Num-of-files is required, nothing in the file itself is required.

Should review these and decide if any of these are dependent, and therefore required for each File.

Note that this is true in many other cases, need to find them all and come up with a plan for each.

The complete list of messages/classes that exhibit this are:

• C2MS Message Envelope
• Telemetry Processed Frame Message
• Mnemonic Value Response Message
• Mnemonic Value Data Message
• Archive Mnemonic Value Data Message
• Device Message
• Resource Message
• Product Request Message
• Product Response Message
• Product Message
• Simple Service Message
• Archive Message Retrieval Request

Make obviously required sub-element fields required in the documentation

Update some fields from Optional to Dependent or Required for sub-elements. This is on a case-by-case basis. In some cases, there are no obvious patterns for what fields might be Required in a given sub-element, so we try to do it only where there is obvious clarity that can be expressed.

NOTE: Changing a field from optional to required is technically not backward compatible. However in each of the instances below that are being changed, the change is being made because in practice the field is de facto required and this change is simply catching up with that need. For example, in Archive Message Retrieval Request, it is technically allowed in 1.1 to designate a FIELD with neither a NAME nor CONTENT, but it would have no meaning, and would therefore be incorrect to do so. Both are required in practice and are now being marked as required.

The following changes (if any) are being made in support of each message type that has this situation:

• C2MS Message Envelope - no change. The sub elements are constructed in this way to allow maximum flexibility to the user. It would be heavy-weight to mark every field as dependent and say that at least one must be present. Although it would be technically accurate to do so, it would be more messy than helpful. Here, we leave this the way it is and leave the user to (in practice) use the message in an assumed way that has at least one of the many possible values filled in.

• Archive Message Retrieval Request - Here it is non-sensical to send a request with a "FIELD" that does not have both the NAME of the field and the CONTENT match for the field. Therefore, the table and diagram are being updated to make these both required for each FIELD.

• Device Message - Again, it is non-sensical to have a Device Parameter that does not have at least both a NAME and a VALUE. Therefore, the table and diagram are being updated to make NAME required for each Device Parameter. However, PARAM-VALUE is new in C2MS12-8 Resolution, so can't be made required. VALUE is being deprecated, so no need to do anything with it.

• Resource Message - Similar to C2MS Message Envelope, above, the fields in these sub elements are much more free-form, with the user able to use any combination of them. Technically, it is true that at least one in each sub-element should be present. However, this message is being deprecated in C2MS12-31, so no action will be taken on this one, here.

• Telemetry Processed Frame Message- Here the new VALUE (From C2MS12-8 resolution) should be required in Sample. However, because this field is being introduced in 1.2, it is completely backward-breaking to make it required, because it didn't exist in prior versions, so no change for this.

• Mnemonic Value Response Message- Here the new VALUE (From C2MS12-8 resolution) should be required in Sample. However, because this field is being introduced in 1.2, it is completely backward-breaking to make it required, because it didn't exist in prior versions, so no change for this.

• Mnemonic Value Data Message- Here the new VALUE (From C2MS12-8 resolution) should be required in Sample. However, because this field is being introduced in 1.2, it is completely backward-breaking to make it required, because it didn't exist in prior versions, so no change for this. This Message is an interesting case because in the closely-related MVAL Response Message Mnemonic.name and .status are required, but not in this message... which is obviously wrong, so correcting here to note it as required. In practice it already is, so though this is a technically breaking change, in practice there is no case when these fields aren't set.

• Archive Mnemonic Value Data Message- Here the new VALUE (From C2MS12-8 resolution) should be required in Sample. However, because this field is being introduced in 1.2, it is completely backward-breaking to make it required, because it didn't exist in prior versions, so no change for this. This Message is an interesting case because in the closely-related AMVAL Response Message Mnemonic.name and .status are required, but not in this message... which is obviously wrong, so correcting here to note it as required. In practice it already is, so though this is a technically breaking change, in practice there is no case when these fields aren't set.

• Product Request Message - Either INPUT-FILE.n.URI or INPUT-FILE.n.DATA must be present. There are several other fields in this message that needed clarification as shown in the table changes and there is new supporting text after the table to help make sense of the various fields. For example, there is a URI a the top level of the request message and also a URI in each input file, each with very distinct meaning.

• Product Response Message - as messy as Product Request Message is for this issue, Product Response Message is very straight forward: For each File "DATA" is required. Although this is moving from an optional to a required field, note that the File in-practice, this is the de facto case.

• Product Message -Same as Product Response Message, above.

• Simple Service Message - Each Parameter must at least have a VALUE. NAME, is optional, because Parameters could be positional. However, in this case, no changes is being made because Simple Service messages are already being deprecated in C2MS12-22. Assuming that issue is accepted by the RTF, there is no reason to update Simple Service Request with this adjustment. Should that issue wind up not being accepted, we will need to come back here to make the adjustment here.