The InputSetType has a InputParameterInstanceRefType as well as a ConstantType.
The ArguementInputSetType has a InputParameterInstanceRefType as well as a InputArgumentInstanceRefType.
The inconsistency causes some confusion as to usage.

Add Constant element back to ArgumentInputSetType complexType

Propose to restore the access to provided Constant values from the ArgumentInputSetType. There is one other discrepancy in that the Constant cannot be accessed without providing a name. At present, the "constantName" attribute is optional, which means it really cannot be referenced from within the algorithm.

First we want to make the "constantName" attribute a required field:

Before:

<complexType name="ConstantType">
<annotation>
<documentation xml:lang="en">Names and provides a value for a constant input to the algorithm. There are two attributes to Constant, constantName and value. constantName is a variable name in the algorithm to be executed. value is the value of the constant to be used.</documentation>
</annotation>
<attribute name="constantName" type="string"/>
<attribute name="value" type="string" use="required"/>
</complexType>

After (attribute and annotation update):

<complexType name="ConstantType">
<annotation>
<documentation xml:lang="en">Names and provides a value for a constant input to the algorithm. There are two attributes to Constant, constantName and value. constantName is a variable name in the algorithm to be executed. value is the value of the constant to be used.</documentation>
</annotation>
<attribute name="constantName" type="string" use="required">
<annotation>
<documentation xml:lang="en">Supply a name for the constant to be used to access this value from within the algorithm.</documentation>
</annotation>
</attribute>
<attribute name="value" type="string" use="required">
<annotation>
<documentation xml:lang="en">Supply the constant value in the form of the data type needed in the algorithm.</documentation>
</annotation>
</attribute>
</complexType>

Now we consider adding back the missing Constant element to the ArgumentInputSetType:

Before:

<complexType name="ArgumentInputSetType">
<annotation>
<documentation xml:lang="en">Identical to InputSetType but supports argument instance references.</documentation>
</annotation>
<choice maxOccurs="unbounded">
<element name="InputParameterInstanceRef" type="xtce:InputParameterInstanceRefType">
<annotation>
<documentation xml:lang="en">Reference a parameter to serve as an input to the algorithm.</documentation>
</annotation>
</element>
<element name="InputArgumentInstanceRef" type="xtce:ArgumentInstanceRefType">
<annotation>
<documentation xml:lang="en">Reference an argument to serve as an input to the algorithm.</documentation>
</annotation>
</element>
</choice>
</complexType>

After:

<complexType name="ArgumentInputSetType">
<annotation>
<documentation xml:lang="en">Identical to InputSetType but supports argument instance references.</documentation>
</annotation>
<choice maxOccurs="unbounded">
<element name="InputParameterInstanceRef" type="xtce:InputParameterInstanceRefType">
<annotation>
<documentation xml:lang="en">Reference a parameter to serve as an input to the algorithm.</documentation>
</annotation>
</element>
<element name="InputArgumentInstanceRef" type="xtce:ArgumentInstanceRefType">
<annotation>
<documentation xml:lang="en">Reference an argument to serve as an input to the algorithm.</documentation>
</annotation>
</element>
<element name="Constant" type="xtce:ConstantType">
<annotation>
<documentation xml:lang="en">Supply a local constant name and value to input to this algorithm.</documentation>
</annotation>
</element>
</choice>
</complexType>

Lastly, correct the missing annotation/documentation in the original InputSetType complexType. This is not a functional change. We should also remove the minOccurs attribute since it is not needed within the choice.

Before:

<complexType name="InputSetType">
<choice maxOccurs="unbounded">
<element name="InputParameterInstanceRef" type="xtce:InputParameterInstanceRefType"/>
<element name="Constant" type="xtce:ConstantType" minOccurs="0"/>
</choice>
</complexType>

After:

<complexType name="InputSetType">
<choice maxOccurs="unbounded">
<element name="InputParameterInstanceRef" type="xtce:InputParameterInstanceRefType">
<annotation>
<documentation xml:lang="en">Reference a parameter to serve as an input to the algorithm.</documentation>
</annotation>
</element>
<element name="Constant" type="xtce:ConstantType">
<annotation>
<documentation xml:lang="en">Supply a local constant name and value to input to this algorithm.</documentation>
</annotation>
</element>
</choice>
</complexType>

Items that previously were typed as FixedIntegerValueType but were changed to become long need to be revisited to update the documentation annotation. For instance IntegerDataType initialValue attribute documentation:
"Default/Initial value is always given in calibrated form. Default is base 10 form; binary, octal, or hexadecimal values may be given by preceding value with 0[b|B], 0[o|O|, 0[x|X] respectively."
Such forms no longer validate against the schema.

Fix the Parameter/Argument IntegerDataType base 10 documentation miss

In the schema complexType IntegerDataType, there is an attribute named initialValue:

<attribute name="initialValue" type="long">
<annotation>
<documentation xml:lang="en">Default/Initial value is always given in calibrated form. Default is base 10 form; binary, octal, or hexadecimal values may be given by preceding value with 0[b|B], 0[o|O|, 0[x|X] respectively.</documentation>
</annotation>
</attribute>

The intention in XTCE 1.2 was to remove the capability to use the binary, octal, and hex flexibility for specifying the number. In XTCE 1.2, we failed to remove this from the documentation element.

Modify the attribute to be defined as:

<attribute name="initialValue" type="long">
<annotation>
<documentation xml:lang="en">Default/Initial value is always given in calibrated form. Specify the value as a base 10 integer.</documentation>
</annotation>
</attribute>

For the parallel type, ArgumentIntegerDataType, also apply the identical attribute block replacing the initialValue attribute.

For instance the documentation for the the ArgumentIntegerDataType says that it is identical to the IntegerDataType. However the initialValue attribute is types as a FixedIntegerValueType whereas the initialValue attribute for the IntegerDataType is typed as long.

IntegerDataType and ArgumentIntegerDataType Now Consistent

This issue appears to have been corrected based on the report of XTCE13-32 with resolution XTCE13-53.

<element name="RelativeTimeAgumentType" type="xtce:RelativeTimeArgumentType">
RelativeTimeAgumentType should have an "r" in it.

Correct Misspelled RelativeTimeAgumentType

The element "RelativeTimeAgumentType" should be "RelativeTimeArgumentType".

This should be ArgumentAssignmentList, with an "n".

Correct Spelling Error of ArgumentAssigmentList in MetaCommandStepType

Within the schema MetaCommandStepType definition, the element ArgumentAssigmentList is missing the "n" and should be spelled as ArgumentAssignmentList.