Scenarios for fields

[fixtradingcommunity]

Scenarios for fields

[donmendelson]

...field level scenarios should really be anything more than subsets of valid values, similar to messages and components where it is about subsets of fields inside.

Rather than having field scenarios, we can define scenarios of code sets and point to them on field references in a message or component, like this:

component Parties scenario inbound
-- fieldRef PartyID
-- fieldRef PartyRole codeSet PartyRoleCodeSet scenario inbound

component Parties scenario outbound
-- fieldRef PartyID
-- fieldRef PartyRole codeSet PartyRoleCodeSet scenario outbound

[donmendelson]

Notes from June 20 meeting:

• Field level scenarios proposed: the same field tag and name but different definitions by asset classes, etc. Different uses of a field may have different rules for conditionally required. Also, they may use different code sets. Should code sets also have scenario names? (We already have scenarios for messages and components.)
• Party roles are often enriched on outbound messages, so different code sets.
• Can we give-up in-line definition of code sets and fields? It complicates the schema to look for everything two ways.

[donmendelson]

We have implemented message and component like this: a common name like "ExecutionReport" or "Instrument" plus a scenario name, and each scenario instance has a unique numeric ID. For the most part, FIX users don't the numeric IDs of messages and components although they have long existed in FIX Repository. Their only requirement is uniqueness for cross-references. Computationally, a single numeric ID is preferable to a concatenated string key.

Fields are different because users do know a lot of common tags, like 44 for Price, 55 for Symbol. Also, field tags go on the wire in tag value encoding, while message and component IDs do not. Therefore, we need to keep the tags the same to work with existing FIX engines, even when there are multiple scenarios for a field.

So field scenarios must be uniquely referenced in Orchestra by field name + scenario name, rather than by tag.

Should we make components and messages work that way as well? That is referenced by name + scenario rather than numeric ID with each scenario sharing the same numeric ID? Advantage: same behavior as fields. Disadvantage: cross references based on a multi-part key.

[donmendelson]

There is another reason not to use a numeric ID for referential integrity although it is computationally better. When EPs that propose new fields are first written , the new field tag is usually marked TBD and assigned later when the EP is approved. If the key is name + scenario, then the numeric ID can be assigned a dummy value at first and changed later without breaking integrity, so long as the name does not change.

[kleihan]

I think there should be a top level distinction for field scenarios as follows:

• Scenario representing a message/component context
• Scenario representing a subset of valid values (if applicable)
• Scenario representing a different semantic in a given context

Fields often get their semantic from the message or component context, e.g. LastPx. These are scenarios defined by FIX and should not be user-defined. Using subsets should be the most common case for scenarios, e.g. subset of ExecType values. The last one should be rare as it can easily be confusing when a field in a message or component can have more than one meaning. An example for that are differences due to asset classes. But again, that would rather be pre-defined by FIX.

In order to also give a negative example: OrderQty in OrderCancelReplaceRequest is always the total quantity of an order. There should not be a field level scenario where this is suddenly the remaining quantity. SO the question is if field level scenarios should really be anything more than subsets of valid values, similar to messages and components where it is about subsets of fields inside.

[donmendelson]

The other desired feature is have context-specific documentation on a field rather than defining the field multiple times as scenarios.

This can be accomplished in the current schema by adding scenario-specific documentation to a fieldRef in a scenario of a message or component.

An alternative would be to add a context or scope attribute to the documentation element. This would be analogous to skos:scopeNote used in FIX vocabulary. For an example in the source document, see FIX Glossary definition of term "Investor ID". It gives one definition "For equities" and another "For CIV".

[donmendelson]

See "Eliminating redundant data in Orchestra files" #33 for discussion of normalization of identifiers. That issue argues for keeping only numeric identifiers for field references (tags) and not names.