Question: combining / splitting codesets

[YuvalCohen]

This is a question only. (sorry in advance, I did not find a better place to submit my question).

One of our clients currently has an orchestra repository. (Hopefully this will become public in the [near ?] future).

Q1. There is an attribute which its type is enumerated (codeset). In many cases we wish to restrict the values to be only sub-set of the available values. What is the best way to do so?
Here is a practical example:
The FIX tag PutOrCall(201) may be:

• restricted to be only the two main values (PUT or CALL)
• restricted to be PUT, CALL or OTHER
• restricted to be PUT, CALL or CHOOSER
• not restricted at all (i.e. may be either PUT, CALL, OTHER or CHOOSER).

All the above restrictions are per message (which are called 'Template') (/or component)

What would be the recommended way to design this in orchestra repository?

Q2. The client has two codesets (one contains approximately 200 enumeration values and the other contains each contains approximately 15 enumeration values). The two sets of enumerations have no common value.
They wish to define ONE attribute that can be either a value from the first enumeration or from the second enumeration.
I am sorry not to be able to provide a proper example for this (in public). I may be able to elaborate further if needed.

Again, same question, what is the recommended way to design this in orchestra repository?

Last, please let me know if there is a better place to submit such questions.

Many thanks for any help!
Yuval

[donmendelson]

@YuvalCohen, this forum is fine for public questions. Other resources include FIX Forum and iMeetCentral for discussion within the Orchestra working group.

Let me answer Q1 first. Different use cases of a code set are supported in the Orchestra schema. We call a use case a scenario. It is identified by the code set name plus a scenario name. Different scenarios of a code set may share some code values, or they may be disjoint.

They may be presented two ways. The first is just list the supported codes in a code set.

<fixr:codeSet type="int" id="201" name="PutOrCallCodeSet" scenario="orderEntry">
<fixr:code value="0" id="201001" name="Put"/>
<fixr:code value="1" id="201002" name="Call"/>
</fixr:codeSet>

The code set scenario is attached to a field like this:

<fixr:field id="201" name="PutOrCall" type="PutOrCallCodeSet" scenario="orderEntry">

Alternatively, you list all possible codes but mark some of them as unsupported for a particular use case. For example, above could add:

<fixr:code value="3" id="201003" name="Chooser" supported="forbidden"/>

[donmendelson]

Regarding Q2 above: I'm not sure I understand the requirement. Are you saying that you wouldn't know until runtime which code set applies, based on other values in a message?

[YuvalCohen]

Regarding Q2 above: I'm not sure I understand the requirement. Are you saying that you wouldn't know until runtime which code set applies, based on other values in a message?

Not exactly,
Ideally, there should be 3 fields:
first field. that its type is the first codeset
second field that its type is the second codeset
third field that its type is the union of both codesets. i.e. it may hold any value from either the first codeset or the second codeset.

I hope it helps.

[kleihan]

@YuvalCohen, do you mean that a field should be able to have values from more than one code set?

[donmendelson]

Currently, there is no syntax in the schema to indicate a union of codesets. (I think restriction is the more common use case.)

The closest thing is a union datatype, but I've argued elsewhere that unions of datatypes should be handled in the datatype section rather than on fields.

[YuvalCohen]

@YuvalCohen, this forum is fine for public questions. Other resources include FIX Forum and iMeetCentral for discussion within the Orchestra working group.

Let me answer Q1 first. Different use cases of a code set are supported in the Orchestra schema. We call a use case a scenario. It is identified by the code set name plus a scenario name. Different scenarios of a code set may share some code values, or they may be disjoint.

They may be presented two ways. The first is just list the supported codes in a code set.

<fixr:codeSet type="int" id="201" name="PutOrCallCodeSet" scenario="orderEntry">
<fixr:code value="0" id="201001" name="Put"/>
<fixr:code value="1" id="201002" name="Call"/>
</fixr:codeSet>

The code set scenario is attached to a field like this:

<fixr:field id="201" name="PutOrCall" type="PutOrCallCodeSet" scenario="orderEntry">

Alternatively, you list all possible codes but mark some of them as unsupported for a particular use case. For example, above could add:

<fixr:code value="3" id="201003" name="Chooser" supported="forbidden"/>

Thanks very much,
Can you please provide further detail.

Please consider the following code:

<fixr:component id="100000" name="put_or_call_only">
    <fixr:fieldRef id="201" name="PutOrCall"/>
</fixr:component>


<fixr:component id="100001" name="put_call_or_chooser">
    <fixr:fieldRef id="201" name="PutOrCall"/>
</fixr:component>

what is the code that I need to add to restrict the first component (id="100000") to have only two values and the second component (id="100001") to have three values [according to the components names)?

Many thanks in advance.

[YuvalCohen]

@YuvalCohen, do you mean that a field should be able to have values from more than one code set?

Yes.
field 1 may have values from codeset 1.
field 2 may have values from codeset 2.
field 3 may have values from codesets 1 or 2.

Hanno, Consider an easyjet plane:
codeSet leftColumnSeats contains seats A, B and C.
codeSet rightColumnSeats contains seats D, E and F.
field passengerSeat may be A, B, C, D, E or F.

(Now Don and Jim, consider delta plane... )

[donmendelson]

@YuvalCohen, add the scenario name of the field.

<fixr:fieldRef id="201" scenario="put_call_or_chooser"/>

BTW in the current RC5 schema, the fieldRef only has id and scenario attributes, name is redundant.

[YuvalCohen]

@YuvalCohen, add the scenario name of the field.

<fixr:fieldRef id="201" scenario="put_call_or_chooser"/>

BTW in the current RC5 schema, the fieldRef only has id and scenario attributes, name is redundant.

Thanks,
Does it mean that I need to define 4 codesets for the 4 scenarios:

• scenario 1: 2 values PUT, CALL
• scenario 2: 3 values PUT, CALL, CHOOSER
• scenario 3: 3 values PUT, CALL, OTHER
• scenario 4: 4 values PUT, CALL, OTHER, CHOOSER.

[donmendelson]

@YuvalCohen, yes a code set scenario for each use case. You may propose a syntax for code set union if you think it has general applicability. Theoretically, code set could have set operations, listed in ISO 11404 as:

IsIn, Subset, Equal, Difference, Union, Intersection, Empty, Setof, Select

[kleihan]

Please consider the following code:

<fixr:component id="100000" name="put_or_call_only">
    <fixr:fieldRef id="201" name="PutOrCall"/>
</fixr:component>


<fixr:component id="100001" name="put_call_or_chooser">
    <fixr:fieldRef id="201" name="PutOrCall"/>
</fixr:component>

what is the code that I need to add to restrict the first component (id="100000") to have only two values and the second component (id="100001") to have three values [according to the components names)?

Many thanks in advance.

@YuvalCohen, what I do not understand is why you are creating two components out of a single field. Components should be existing FIX components to begin with. You could have two scenarios for the field PutOrCall(201), each having a different datatype (=subset of the full codes). Or two scenarios for the Instrument component which has PutOrCall(201) inside. Or two message scenarios for the same message, each with the field PutOrCall(201) and a different datatype.
The choice of the scenarios level depends on the overall design, Orchestra gives you many options. Creating a user defined component (as it looks to me) is not the way it is supposed to be. Maybe I am missing something, @donmendelson?