[Legacy iMC Thread] Use the scenario implicitly according to the message context

[francescoloconte]

[Poster Xavier B.]

I'm interested in the scenario specification revamp since it was already my request two years ago (https://fixprotocol.imeetcentral.com/orchestra/folder/all/WzIsNzQyMzEwOTNd/).

Let me give the example of execution reports to illustrate my suggestion. Let say we just want to define a scenario per ExecType and the message definition is the same for all scenarios (to simplify). The only difference would be ExecTypeCodeSet which would accept a single value for each scenario.

In this example, I would like to be able to define a single execution report definition and a single definition for each field. In particular, the definition of ExecType is the same for all scenarios:

<fixr:fields>
        <fixr:field id="150" name="ExecType" type="ExecTypeCodeSet" />
</fixr:fields>

The only element I would like to define for each scenario is the code set:

<fixr:codesets>
        <fixr:codeSet name="ExecTypeCodeSet" type="char" scenario="acknowledgement">
            <fixr:code value="0" />
        </fixr:codeSet>
        <fixr:codeSet name="ExecTypeCodeSet" type="char" scenario="trade">
            <fixr:code value="F" />
        </fixr:codeSet>
</fixr:codesets>

How would it be evaluated? If the session receives a trade, it should be able to define that the message scenario is "trade" (according to the scenario definitions/conditions). If not, it would be considered as the "base" scenario. Then the session searches for an execution report definition in the Orchestra file for the "trade" scenario. If there is one, it uses this definition to validate the message, otherwise it uses the "base" execution report definition. Same for the fields. If the message definition contains a reference to the field ExecType, the session searches the ExecType definition for the scenario "trade". If it does not exist, it searches the definition for the scenario "base". And finally same process for the code set.

This proposition is fully compatible with the current Orchestra syntax. It only changes the semantic.

Side notes:

• If we allow a scenario to inherit from another scenario (for example, scenario "tradeForStrategy" extends "trade"), then the session will have to search for a definition from the child scenario to the root one (base).
• Can a message to be part of multiple scenarios? For example, scenario "trade" + scenario "strategy"? I guess it would become too complicated.

[francescoloconte]

Hi Xavier,

In your comment, you say "If the session receives a trade, it should be able to define that the message scenario is "trade" (according to the scenario definitions/conditions)". Could you please elaborate on how the session identifies the incoming execution report as belonging to the "trade" scenario? What does it actually check?

[francescoloconte]

[Poster Xavier B.]

Same as currently. According to Orchestra specification, "The task of mapping an actual received message to a scenario declaration in Orchestra is left to implementations."

Theoretically the application is able to check if there is at least one scenario for which the message matches the definition. If there is at least one, then the message can be considered as valid. In my example, the message does not match the "acknowledgment" scenario if 150=F (because ExecTypeCodeSet does not contain the value "F" for the scenario "acknowledgment") but matches the "trade" scenario. So the session can consider the message as valid "trade".

[francescoloconte]

I am currently working on a "revamp" of the scenarios based on the suggestions I made on the last call. I am not sure whether it will achieve your specific goal though, because I am not sure I understood clearly what it is. Perhaps it is to specialize API elements (code sets, fields, groups, or components), while maintaining only 1 definition for a specific message?

One thing I noticed in your example is that you say, "I would like to be able to define a single execution report definition and a single definition for each field." From the rest of your comments, I understand that while you would specialize the ExecTypeCodeSet (for 'acknowledgement' and 'trade'), the message API would only show 1 ExecutionReport message. However, this hides the fact that there would be, in reality, 2 ExecutionReport messages supported by the API - one for 'base' and one for 'trade'. Furthermore, if one were to specialize the API further, there may be even more implicit (and valid) ExecutionReport messages.

One of the goals of my design is to make it clear to the API designer what the supported API messages are, whether 'base' or belonging to a specific scenario, to make the API very explicit.

This has several advantages. For example, it makes the implementation of scenario classification easier since the messages to be classified are evident. It allows code generators to instantiate scenario-specific messages, e.g., MessageFactory(<message type>, <scenario type>). Moreover, it facilitates visualization of the API from "scenario angles" (or 'dimensions'), i.e., to show all messages and API elements belonging to the "equity" API. Additionally, it should enable messages to belong to multiple scenarios, i.e., to multiple dimensions, such as an ExecutionReport with ProductType='equity' & VenueType='MIFID', or an ExecutionReport with ProductType='IRS' & VenueType='CFTC'.

This approach will also reduce the efforts required by the classification process you described, as it will eliminate the fall-back events (i.e., check --> miss --> fall back to 'base'). To support (and perhaps constrain a bit) the implementation of message classification, I will also propose the introduction of explicit classifiers.

I will be circulating the document soon. I look forward to your feedback.

[francescoloconte]

[Poster Xavier B.]

Sorry if my explanation was not clear enough. Maybe my example was confusing. The general idea is: no need to specify a scenario attribute for a fieldRef element; by default it can refer to the same scenario as the one of the message (instead of referring to the "base" scenario by default) (same for other element references). The benefit is that we would not need to define the full message hierarchy to create a new scenario but we could only define an alternate scenario for the specific element.

However I'm not sure my suggestion can work well with the possibility for a message to include multiple scenarios.

I'm waiting for your document. Thank you.

[francescoloconte]

I would like to clarify.

Currently, if you create a message for scenario "A" (Message-A), all references in Message-A will be of type 'base' by default, which is correct and valid, since the 'base' version of the elements already exist. Are you suggesting that they should be of type A by default instead? If that were the case though, upon creating Message-A, most of the references would be invalid, since the corresponding 'A' version of the referenced elements would not exist (yet).

I am sure I do not understand correctly. Could you please explain it more clearly?

In this image for example, you can see a message of scenario "Trade_LastLookOTD", where the reference to "Symbol" uses 'base' by default: https://prnt.sc/9dH2lkWT9r5p

[francescoloconte]

[Poster Xavier B.]

Are you suggesting that they should be of type A by default instead?

Yes.

most of the references would be invalid, since the corresponding 'A' version of the referenced elements would not exist

If the 'A' version does not exist, we would use the parent scenario version.

[francescoloconte]

I understand now the problem you are trying to solve. I think the solution I will propose addresses this, but I look forward to your feedback. My first comment would be that, by marking all references require a "A"-type element by default, but then fall back to "base"-types for most of them, could be a bit misleading. One would read the message specification as requiring "A"-types (since that is what is specified), but then end up with "base"-type elements because the others are not defined - in a kind of hidden way. As the goal I stated above, I would like the API to be explicit, clear, and evident; removing as many assumption as possible (i.e., implicit fall-backs).

[francescoloconte]

[Poster Hanno K.]

Please see FIXTradingCommunity/fix-orchestra-spec#49 that discusses the problem of implicit scenarios in general.