fix-orchestra
fix-orchestra copied to clipboard
FIXTradingCommunity
Usage of field attribute "scenario"
Fields are allowed to have scenarios in the repository schema. Section 2.2.1.1 Field and code set scenarios in the Orchestra spec talks about this:
Like messages and components, fields and code sets now support scenarios in RC4. The main benefit is that a code set can be constrained to different sets of codes in different use cases. For example, PartyRole can have enriched values in outbound messages compared to the requirements for inbound messages. Additionally, field and code sets scenarios can have different documentation than their base implementations.
I wonder why it is not sufficient for code sets to have scenarios, e.g. "BuySell" to limit values to 1=Buy and 2=Sell. Field references in messages, components, and groups also have scenarios. A field definition by itself, e.g. <fixr:field type="SideCodeSet" id="54" name="Side" scenario="BuySell"/>, does not have any meaning unless a code set is defined with the same scenario name "BuySell".
Whenever I need to use Side(54) in any message, component or group with the limited value set, I can add the scenario to the field reference. I do not see the benefit of creating two fields having the same name and type, one for scenario "base" and the other one for scenario "BuySell".
Can anybody offer me a real use case for that field attribute "scenario"? It seems redundant to me.
- Ability to specify documentation and usage of a field.
- Be able to specify the usage and format of the value - different messages scenarios may have different usages and formats of data within the field.
- Consistency with the rest of the repository structure.
On Wed, Feb 10, 2021 at 4:51 PM Hanno Klein [email protected] wrote:
Fields are allowed to have scenarios in the repository schema. Section 2.2.1.1 Field and code set scenarios in the Orchestra spec talks about this:
Like messages and components, fields and code sets now support scenarios in RC4. The main benefit is that a code set can be constrained to different sets of codes in different use cases. For example, PartyRole can have enriched values in outbound messages compared to the requirements for inbound messages. Additionally, field and code sets scenarios can have different documentation than their base implementations.
I wonder why it is not sufficient for code sets to have scenarios, e.g. "BuySell" to limit values to 1=Buy and 2=Sell. Field references in messages, components, and groups also have scenarios. A field definition by itself, e.g. <fixr:field type="SideCodeSet" id="54" name="Side" scenario="BuySell"/>, does not have any meaning unless a code set is defined with the same scenario name "BuySell".
Whenever I need to use Side(54) in any message, component or group with the limited value set, I can add the scenario to the field reference. I do not see the benefit of creating two fields having the same name and type, one for scenario "base" and the other one for scenario "BuySell".
Can anybody offer me a real use case for that field attribute "scenario"? It seems redundant to me.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/FIXTradingCommunity/fix-orchestra/issues/114, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB7Z6SKZIFC34HAZWBDHSVDS6L5XXANCNFSM4XNXGEMQ .
Maybe I was focussed too much on code sets as distinguishing factor for field scenarios. I would not use different field scenarios but different code sets and annotate the code sets. It could also be the other way around. FIX has many fields that use the same enums, e.g. party roles in the various parties components (Root, Nested,...). The field definitions could all use the same code set, e.g. MyPartyRoles, reducing the roles to a small subset. I do not need field scenarios for this. My example above (<fixr:field type="SideCodeSet" id="54" name="Side" scenario="BuySell"/>) confuses code sets scenarios with field scenarios. The name of the field scenario (BuySell) actually expresses the nature of SideCodeSet.
Let's take a different example then that is not about code sets:
<fixr:field type="string" id="22" name="SecurityIDDesc" implLength="10" scenario="Short"/> <fixr:field type="string" id="22" name="SecurityIDDesc" implLength="30" scenario="Long"/>
NewOrderSingle(35=D) uses SecurityIDDesc(22) with scenario Short, only allowing 10 characters. ExecutionReport(35=8) uses SecurityIDDesc(22) with scenario Long, allowing 30 characters, e.g. to enhance the input value with additional information. I would annotate the fields rather than the field references in the messages, especially if many messages use the same scenario (e.g. Short for all order handling messages).
Is this a good use case for field scenarios?
@jimnup Can you give examples that show the difference between the first two of your points?
This is what I was thinking - I am working on an effort where there will be different rules, including implLength that would apply to ClOrdID(11), OrderID(37), and the other related fields.
I am also thinking wouldn't we need field scenarios to indicate which codeset scenario we would be using in a given context?
On Thu, Feb 11, 2021 at 5:07 AM Hanno Klein [email protected] wrote:
Maybe I was focussed too much on code sets as distinguishing factor for field scenarios. I would not use different field scenarios but different code sets and annotate the code sets. It could also be the other way around. FIX has many fields that use the same enums, e.g. party roles in the various parties components (Root, Nested,...). The field definitions could all use the same code set, e.g. MyPartyRoles, reducing the roles to a small subset. I do not need field scenarios for this. My example above (<fixr:field type="SideCodeSet" id="54" name="Side" scenario="BuySell"/>) confuses code sets scenarios with field scenarios. The name of the field scenario (BuySell) actually expresses the nature of SideCodeSet.
Let's take a different example then that is not about code sets:
<fixr:field type="string" id="22" name="SecurityIDDesc" implLength="10" scenario="Short"/> <fixr:field type="string" id="22" name="SecurityIDDesc" implLength="30" scenario="Long"/>
NewOrderSingle(35=D) uses SecurityIDDesc(22) with scenario Short, only allowing 10 characters. ExecutionReport(35=8) uses SecurityIDDesc(22) with scenario Long, allowing 30 characters, e.g. to enhance the input value with additional information. I would annotate the fields rather than the field references in the messages, especially if many messages use the same scenario (e.g. Short for all order handling messages).
Is this a good use case for field scenarios?
@jimnup https://github.com/jimnup Can you give examples that show the difference between the first two of your points?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/FIXTradingCommunity/fix-orchestra/issues/114#issuecomment-777332469, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB7Z6SOBHWUAGCPOVVEMQ7LS6OT7DANCNFSM4XNXGEMQ .
Yes, any non-key fields can be different in a field scenario, including rules.
Let's try the following example. I define two code sets for PartyRole(452) by declaring two data types (FewRolesCodeSet and ManyRolesCodeSet). I also define FewRolesCodeSet and ManyRolesCodeSet as code sets with few/many values of PartyRole(452) as follows (I leave out the actual values for simplicity):
<fixr:codeSet type="int" id="10004" name="FewRolesCodeSet".../> <fixr:codeSet type="int" id="10005" name="ManyRolesCodeSet".../>
I want to use PartyRole(452) in messages A and B but with different data types (code sets). I define the field PartyRole(452) twice as follows and add a scenario name in order to be able to reference it in my message definitions:
<fixr:field type="FewRolesCodeSet" id="452" name="PartyRole" scenario="X"/> <fixr:field type="ManyRolesCodeSet" id="452" name="PartyRole" scenario="Y"/>
I then define my messages A and B with the following field references:
<fixr:fieldRef id="452" scenario="X"/>
<fixr:fieldRef id="452" scenario="Y"/>
It looks as if I always need to also define field scenarios X and Y because otherwise I cannot reference them inside the definitions for messages A and B, correct?
If that is the case, then what purpose do scenarios for code sets have? Staying in the example above, I could alternatively define a single code set with two scenarios as follows (I leave out the actual values for simplicity):
<fixr:codeSet type="int" id="10004" name="PartyRoleCodeSet" scenario="X".../> <fixr:codeSet type="int" id="10005" name="PartyRoleCodeSet" scenario="Y".../>
I define a single field as follows:
<fixr:field type="PartyRoleCodeSet" id="452" name="PartyRole"/>
Is it possible to define my messages A and B whereby the field reference to PartyRole(452) points to different code sets? If not, what is a good example for the use of code set scenarios? I must admit that I may not be seeing the forest for the trees here...
Field scenarios are also needed to change other attributes of the field, not just the supported values.