Appearance and Content Control properties

This is draft content for inclusion as subsection of section 6 in Core Principles.

Appearance and content control properties

There are a number of properties that affect the appearance and support of an element in a structural model or data type. This section discusses these properties and the meaning and behavior of various combinations of them.

Multiplicity

Multiplicity is the property most implementers have the greatest familiarity with and comfort level with. It behaves in almost exactly the same manner as defined in UML. It controls both the minimum and maximum number of repetitions allowed for the element on which the cardinality appears.

The one slight quirk of cardinality appears in Datatypes R2. In Datatypes R2, the collection itself is represented as a data element that in turn contains the repetitions of the selected type. The result is that it is possible for a data element to appear representing the collection (number of occurrences = 1), but to have the actual collection be empty (number of occurrences = 0). The methodology has not yet evolved to address this. A likely outcome will be splitting the "multiplicity" property into two aspects. One will be be an "appearance" property that governs whether the element must appear in the instance or not. The second will be "true" multiplicity and will only appear for collection datatypes. It will govern the minimum and maximum number of occurrences permitted within the collection.

Until this change occurs however, a minimum multiplicity of 0 SHALL be interpreted as meaning the element does not need to appear in the instance as well as meaning, for collection types, that the collection may be empty. A minimum multiplicity of 1 or more SHALL be interpreted as meaning the element must appear in the instance as well as indicating that the collection must contain at least the specified number of occurrences.

Mandatory

Despite its name, mandatory does not indicate whether the specified element must appear in an instance. Rather, it indicates whether the element is permitted to have a null value. If mandatory is true, then null values are prohibited. If a valid value cannot be specified for the element, then the class, attribute or property containing the element must be omitted from the instance. If there is a chain of mandatory elements starting from the root of the instance where a leaf-level mandatory cannot be satisfied, it is not possible to create an instance at all. For this reason, designers should use considerable caution when setting isMandatory to true. It should only be done when it would be dangerous, impossible or nonsensical to process the instance if the specified data element did not have a valid value.

In most cases, the requirement that a non-null value be specified does imply that mandatory elements will need to appear in instances. This is because the "default" value for most elements is the null flavor NI. If an element is omitted, it will default to a null value and thus break the "no null values for mandatory elements" rule. However, this can be avoided by declaring a non-null default or fixed value for the element. For example, actionNegationInd is defined in the RIM as having a default value of "false". It would be possible to flag actionNegationInd as "mandatory", but still omit it from the instance. The receiver would detect the element was missing, infer the default value and the "no null value" constraint would not be violated.

Note: While the methodology theoretically allows for mandatory elements with non-null default values to be omitted from instances, the design tools currently in use force the minimum cardinality to always be at least 1 for mandatory elements. This results in a requirement that mandatory elements always appear in instances.

Conformance

Despite having values such as "required", the conformance property does not directly make a statement about whether an element must be populated in an instance. Instead, conformance speaks to whether the specified element must be supported or not. A value of "required" indicates that the system must be capable of sending or of receiving and processing the value, should data for the value actually exist.

It is quite possible for a "required" element to not appear in an instance either because the user chose not to enter that data, or because the business rules in force prevented disclosure of the data element in the circumstance that led to the creation of the instance. So long as the system is able to expose and otherwise manipulate the element in a manner consistent with other data elements it also supports and consistent with the intended use of that system, it has met the onus of the "required" conformance property. For example, a system intended to capture data from a human user should be able to allow the user to enter the element. A system intended to perform logical analysis should be able to take into account the value of the element as it relates to the analysis performed. A system intended to transmit information must include the value for the element in outbound transmissions provided the intended recipient is permitted to see the element value based on application configuration, privacy policies and similar rules.

Default and Fixed values

Some attributes and datatype properties can have fixed or default values, namely those whose content can be fully expressed as a single string. Complex types such as CD, EN or AD cannot be expressed as strings and therefore cannot have default or fixed values.

The presence of a default or fixed value in a model design can influence whether a data element must be specified when the instance is sent over the wire. In some ITSs, data elements may be omitted when the value is fixed by the model, or when the data value for the element is the same as the default value. Note that default (and even fixed) values can also be null flavors. This is done using the convention of expressing the value as "NullFlavor.x" where x is the desired null flavor. For example, a default of "NullFlavor.NA" would mean that if the element were omitted, the receiver should assume that the element was "not applicable".

Property combinations

The table below lists various combinations of the above properties and provides a description of whether the combination is "legal" as well as the interpretation and behavior associated with that combination.

Minimum Multiplicity	isMandatory	Conformance	Default / Fixed Value	Interpretation
0	false	required	no	The element can be omitted from the instance. However, it must be supported and be able to be processed. If present, it can have a null flavor. If absent, it is treated as if it were the null flavor NI.
0	false	required	yes	The element can be omitted from the instance. However, it must be supported and be able to be processed. If present, it can have a null flavor. If omitted, it is presumed to have the specified default or fixed value.
0	false	not permitted	no	The element must not be specified. If present, it may result in an error from the receiving system.
0	false	not permitted	yes	The element must not be specified. If present, it may result in an error from the receiving system.
0	false	ignored	no	The element can be omitted. If present, whether it has a null flavor or not, it will be ignored by the receiver.
0	false	ignored	yes	The element can be omitted. If present, whether it has a null flavor or not, it will be ignored by the receiver.
0	true	required	no	Not a legal combination. Mandatory elements must have either minimum Multiplicity of 1 or a non-null default or fixed value.
0	true	required	yes	This combination is legal only if the default or fixed value is not a null flavor. The element can be omitted from the instance. However, it must be supported and be able to be processed. If present, it must not have a null flavor. If omitted, it is presumed to have the specified default or fixed value.
0	true	not permitted	no	Not a legal combination. Mandatory elements must have conformance of required and either minimum Multiplicity of 1 or a non-null default or fixed value.
0	true	not permitted	yes	Not a legal combination. Mandatory elements must have conformance of required
0	true	ignored	no	Not a legal combination. Mandatory elements must have conformance of required and either minimum Multiplicity of 1 or a non-null default or fixed value.
1	false	required	no	The element must be specified and must be supported and be able to be processed. However, it can have a null flavor.
1	false	required	yes	The element must be specified and must be supported and be able to be processed. However, it can have a null flavor. The value must be sent even if it matches the default.
1	false	not permitted	no	Not a legal combination. Conformance of "Not Permitted" isn't allowed for items with a minimum multiplicity of 1
1	false	not permitted	yes	Not a legal combination. Conformance of "Not Permitted" isn't allowed for items with a minimum multiplicity of 1
1	false	ignored	no	The element must be present in the instance but will be ignored present, whether it has a null flavor or not.
1	false	ignored	yes	The element must be present in the instance but will be ignored present, whether it has a null flavor or not.
1	true	required	no	The element must be specified and must be supported and be able to be processed. Furthermore, it must not have a null flavor.
1	true	required	yes	The element must be specified and must be supported and be able to be processed. Furthermore, it must not have a null flavor. The value must be sent even if it matches the default. The default or fixed value must not be a null flavor
1	true	not permitted	no	Not a legal combination. Mandatory elements must have conformance of required
1	true	not permitted	yes	Not a legal combination. Mandatory elements must have conformance of required
1	true	ignored	no	Not a legal combination. Mandatory elements must have conformance of required
1	true	ignored	yes	Not a legal combination. Mandatory elements must have conformance of required

NOTE: Elements that have a conformance of "undetermined" must follow the rules for "required", "ignored" or "not permitted", depending on the decision of the implementer on whether to support the element or not. Elements with a conformance of "required for consumer" or "required for initiator" will follow the respective behaviors of "required" and "undetermined" depending on whether they are sending or receiving.