search

FIXTradingCommunity / fix-orchestra

Machine readable rules of engagement
Apache License 2.0
71 stars 34 forks source link

[repository schema] Does use of fixr:oidGrp for complex type "codeType" imply support of scenarios for individual codes? #175

Closed kleihan closed 1 year ago

kleihan commented 1 year ago

The repositorytypes.xsd file defines codes of a code set as follows (truncated):

    <xs:complexType name="codeType">
        <xs:sequence>
            <xs:element name="annotation" type="fixr:annotation" minOccurs="0"/>
        </xs:sequence>
        <xs:attributeGroup ref="fixr:oidGrp"/>
                ...
        <xs:attributeGroup ref="fixr:entityAttribGrp"/>
    </xs:complexType>

The attribute oidGrp is defined as follows (annotations removed):

    <xs:attributeGroup name="oidGrp">
        <xs:attribute name="id" type="fixr:id_t" use="required"/>
        <xs:attribute name="name" type="fixr:Name_t" use="required"/>
        <xs:attribute name="abbrName" type="fixr:Name_t"/>
        <xs:attribute name="scenario" type="fixr:Name_t" default="base"/>
        <xs:attribute name="scenarioId" type="fixr:id_t" default="1"/>
    </xs:attributeGroup>

Does this mean that a single code in a code set may have scenarios and occur more than once? I think the answer is no due to the uniqueness constraint (xs:key) in repository.xsd related to just the name:

            <xs:sequence>
                <xs:element name="codeSet" type="fixr:codeSetType" minOccurs="0" maxOccurs="unbounded">
                    <xs:key name="codeKey">
                        <xs:selector xpath="fixr:code"/>
                        <xs:field xpath="@name"/>
                    </xs:key>
                </xs:element>
                <xs:element name="annotation" type="fixr:annotation" minOccurs="0"/>
            </xs:sequence>
donmendelson commented 1 year ago

@kleihan, you are correct that the schema does not prevent adding scenarioId to a code element. However, it would have no effect since codes are constrained to be unique by name within a codeSet. To be absolutely correct, we could create something like oidGrp without scenario identification. However, there is a tradeoff between precision and simplicity.

In Orchestra, codes are not first-class objects, only parts of a codeSet. An interesting topic to explore would be equivalent semantics of codes in different codeSets, e.g. Buy in SideCodeSet and PaymentPaySideCodeSet.

kleihan commented 1 year ago

However, there is a tradeoff between precision and simplicity.

Understand, thank you @donmendelson. Semantic equivalence of individual codes increases complexity. PaymentPaySideCodeSet was probably created separately because not all values of SideCodeSet apply. It could already be modeled with Orchestra v1.0 by using code set scenarios and attaching the appropriate scenario to a given field. That would make scenarios relevant for FIX Latest and not just for user applications.

        <fixr:codeSet name="SideCodeSet" id="54" type="char" added="FIX.2.7" scenario="base">
            <fixr:code name="Buy" id="54001" value="1" sort="1" added="FIX.2.7" updated="FIX.5.0SP2" updatedEP="254"/>
            <fixr:code name="Sell" id="54002" value="2" sort="2" added="FIX.2.7" updated="FIX.5.0SP2" updatedEP="254"/>
        </fixr:codeSet>

        <fixr:codeSet name="SideCodeSet" id="54" type="char" added="FIX.2.7" scenario="extendedSell">
            <fixr:code name="Buy" id="54001" value="1" sort="1" added="FIX.2.7" updated="FIX.5.0SP2" updatedEP="254"/>
            <fixr:code name="Sell" id="54002" value="2" sort="2" added="FIX.2.7" updated="FIX.5.0SP2" updatedEP="254"/>
            <fixr:code name="SellPlus" id="54004" value="4" sort="4" added="FIX.2.7"/>
            <fixr:code name="SellShort" id="54005" value="5" sort="5" added="FIX.2.7"/>
            <fixr:code name="SellShortExempt" id="54006" value="6" sort="6" added="FIX.2.7"/>
            <fixr:code name="SellUndisclosed" id="54017" value="H" sort="17" added="FIX.5.0SP2" addedEP="222"/>
       </fixr:codeSet>

A hierarchy of code sets with inheritance appears too complex. A union of two code sets (unionCodeSet, similar to unionDataType), however, could have merit. Then you do not have to repeat the values from the base scenario.