[repositorySchema] datatypes lack scenarios

[donmendelson]

Messages, components, groups, fields, and codesets can have scenarios in Orchestra v1.0, but datatypes do not. This resulted in an unanticipated flaw in the schema that begs resolution in v1.1. In the Orchestra schema, a field has a type. Field type can be one of the FIX datatypes listed in that section, such as int, Price, or UTCTimestamp, or type can refer to a code set. This makes sense since a code set is semantically a specialized datatype that declares a finite set of valid values. The fact that a code set can have scenarios while a datatype cannot breaks cross-references that try to follow two different shapes, and it flat-out fails XML validation. There is no direct band-aid for this XML problem that would be widely acceptable. (I considered assertions enabled by XML Schema v1.1, but that technology is not supported in several programming languages, and it is not a smooth solution anyway.)

Upon reflection, if datatypes were allowed to have scenarios, it would not only solve the XML reference problem for types, but it could be a useful feature. In FIX datatypes, there is currently only "int" for integer while in SBE, integers can be encoded as 8-, 16-, 32-, or 64-bit and signed or unsigned integers. It would be useful to have scenarios of "int" for short and long integers, or ordinals which are only positive numbers. (Example of an ordinal: the level of an order book as 1st, 2nd, 3rd, etc.) Another possible application would be subclasses of Price for equities vs. FX, that have very different precisions, or non-decimal agricultural commodity prices. In short, adding scenarios to datatypes could make them both more targeted and extensible. Furthermore, mapping from datatypes to encodings such as SBE would be more precise.

[donmendelson]

The schema change accepted so far allows datatype scenarios to be declared but the schema does not provide enough attributes to distinguish their values spaces. (It does a little better when mapping to the lexical space of an encoding in the mappedDatatype element.) Examples: How would it distinguish the different precisions of float type scenarios? How would it distinguish an exact decimal used for monetary value from a real number used as a ratio?

[donmendelson]

Data scenarios may obsolete the baseType attribute of datatype.

[kleihan]

FIX tag=value is using the baseType attribute for its encoding. It would be a significant change to remove that in favor of datatype scenarios. Also, it would add scenarios to FIX Latest that it currently does not need anywhere else. An Orchestra user should be able to handle both approaches (base type versus scenario). FIX could also offer a translation utility that converts from base types to scenarios (not vice versa).

[kleihan]

The key for datatypes seems to be the name+scenarioId. Why is this different from e.g. fields where it is either name+scenario or id+scenarioId? Datatypes do not have an ID, just a name. Why is it not name+scenario for datatype keys?

		<xs:key name="datatypeKey">
			<xs:selector xpath="fixr:datatype"/>
			<xs:field xpath="@name"/>
			<xs:field xpath="@scenarioId"/>
		</xs:key>

[kleihan]

Implemented in RC1