C2MS11 — Specify multiplicity for required and optional fields

Set the association multiplicity for required fields to '1' and optional fields to '0..1'

Documentation Change to be Made in 1.1

The following changes will be made:

• Make changes to Section 8 PIM – Message Definitions under Field Name to clarify the notation used for "series".
  
  
  • Add a diagram to illustrate the text
    
    
• Make changes to Section 8 PIM – Message Definitions under Required, Optional, Dependent and Tracking to clarify how R/O/D are used and to separate out Tracking since that does not indicate R/O/D.
  
  
  • Add a diagram to illustrate the text
    
    

Make global changes as represented below:

• Make changes to all Message Diagrams, beginning with Figure 8-2. Message Header Diagram and ending with Figure 8-40. Tracking Data Message Diagram to show multiplicity of each attribute. Note that we no longer need the concept of a block called "Required Fields" and another called "Optional Fields". Additionally, each changed diagram will use fields in the same order as found in the "Additional Information" table for the message to improve readability.
  • This is illustrated in the attached before and after diagrams for the following, each showing a slightly different aspect of the changes:
    • the Directive Response Message
    • the Configuration Status Message
    • the Heartbeat Message
    • the Mnemonic Value Request Message
  • The identical pattern will be applied across all the above mentioned figures. Note that the 'revised' diagrams already show changes previously approved from C2MS11-18 (making all messages subclass C2MS Message which contains a Header) and C2MS11-31 (Clarify the UML diagrams regarding the values for the fields inherited from Message Header).
    
    
• Make changes to all Message "Additional Information" tables, beginning with Table 8-3. Message Header Additional Information and ending with Figure 8-40. Tracking Data Message Diagram to show multiplicity of each attribute. This will verify that all tracking fields are described in the tables clearly.
  • This is illustrated in the "revised text" of this issue with table changes for the same four messages listed above, again, each showing a slightly different aspect of the changes. The identical pattern will be applied across all the above mentioned figures.
    
    
• This proposal constitutes a plan to do the above if voted on, though there will be a follow-on vote with a separate issue/proposal to show all the changes before and after for completeness. Vote 'yes' on this one if you plan to vote 'yes' on the final (to avoid extensive work without commitment).

• If this proposal is accepted, a complete set of before and after images will be provided as part a second issue/proposal and if accepted will be provided as part of the RTF Report assuming that second issue/proposal is accepted.
  • Note that the final images may be a convergence with other voted in global figure changes, such as (but not limited to) C2MS11-18. In other words, if this proposal is accepted and others like C2MS11-18 the proposals are also accepted, all sets of changes will be made in the final "after" images in the RTF Report.