Support for easy constant value setting in fields about fix-simple-binary-encoding

[kleihan]

I believe your example of what you have to do only applies to enumerated fields where th valid values are pre-defined. For fields where the valid value only depends on the data type and range, there already is a simpler way, see the two examples from the SBE 1.0 spec:

<composite name="decimal32" >
    <type name="mantissa" primitiveType="int32" />
    <type name="exponent" primitiveType="int8"
        presence="constant">-2</type>
</composite>

<type name="EurexMarketID" semanticType="Exchange"
 primitiveType="char" length="4" description="MIC code"
 presence="constant">XEUR</type>

Or are you suggesting to also have that capability on the field level, so that a given type can be a constant in one message and not a constant in another?

[donmendelson]

The XML schema already supports constant values of fields. The spec says

Alternatively, fields may be specified as constant. In which case, the data is not sent on the wire, but may be treated as constants by applications.

and

presence=constant | The field has a constant value that need not be transmitted on the wire. Mutually exclusive with value attributes.

Two issues:

• The only examples of constants are for members of composite types, using a constant <type>, or values of an enum. We could add an example of a constant field as @billsegall suggested.
• The description of presence=constant should be more specific to say "Mutually exclusive with attributes minValue, maxValue, and nullValue."

[donmendelson]

On second thought, there is an issue with the XML schema that prevents constant field. The XML complexType fieldType needs to have mixed="true" to allow the value to be set in the contents of a <field> XML element.

The memberType used for member of a composite type already has this property, as do XML complex types enumType, refType, setType, and simpleDataType..

[darthninja1]

I see this issue is still open. Any plans to support constants in message fields as @billsegall suggested?

The commented lines dont work today...

    <sbe:message name="Constants" id="1" description="Constants">
        <field id="1"  name="constant1"  type="SomeEnum" presence="constant" valueRef="SomeEnum.A"/>
        <field id="2"  name="constant2"  type="uint8"    presence="constant" valueRef="SomeEnum.A"/>
        <!--<field id="3"  name="constant3"  type="uint8"    presence="constant" value="1"/>-->
        <!--<field id="4"  name="constant4"  type="uint8"    presence="constant">1</field>-->
    </sbe:message>

[donmendelson]

@darthninja1 , using XMLSpy to validate the XML, I found that your last example is valid using the latest version 2.0 RC1 schema.

(schemaLocation elided)

<sbe:messageSchema xmlns:sbe="http://fixprotocol.io/2017/sbe" version="0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
	<types>
		<enum name="SomeEnum" encodingType="char">
			<validValue name="A">A</validValue>
		</enum>
	</types>
	 <sbe:message name="Constants" id="1" description="Constants">
        <field id="1"  name="constant1"  type="SomeEnum" presence="constant" valueRef="SomeEnum.A"/>
        <field id="2"  name="constant2"  type="uint8"    presence="constant" valueRef="SomeEnum.A"/>
        <!--<field id="3"  name="constant3"  type="uint8"    presence="constant" value="1"/>-->
        <field id="4"  name="constant4"  type="uint8"    presence="constant">1</field>
    </sbe:message>
</sbe:messageSchema>

[mjpt777]

If this is to be supported in 2.0 then we need clear rules of precedence. What if someone provides a valueRef and provides the character data like in constant4? Is it an error or is there precedence.