Closed billsegall closed 6 years ago
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?
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:
<type>
, or values of an enum. We could add an example of a constant field as @billsegall suggested.presence=constant
should be more specific to say "Mutually exclusive with attributes minValue, maxValue, and nullValue."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
..
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>
@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>
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.
Where I have a constant field in a message I want to be able to more simply set a constant value for it. As an example I currently need to do something like this:
and I'd like to be able to do this:
Essentially I think we could support the value= tag on a constant field in a backward compatible way to aid usability and clarity.