PUBLIC COMMENT PERIOD – FIX Orchestra V1.0 Release Candidate 5

PUBLIC COMMENT PERIOD – FIX Orchestra V1.0 Release Candidate 5

This proposal from the FIX Orchestra Subgroup provides the details of the FIX Orchestra Technical Standard Release Candidate 5 V1.0.

FIX Orchestra was conceived as machine readable rules of engagement between counterparties. As such, it is a standard for exchange of metadata about the behavior of FIX applications. Orchestra is intended to cut time to on-board counterparties and improve accuracy of implementations.

FIX Orchestra does not change FIX protocol itself in any way, nor does it make obsolete existing FIX engines or tools.

The fifth release candidate documents for FIX Orchestra can be found here:

https://www.fixtrading.org/standards/fix-orchestra/

The key enhancements in Version 1.0 Release Candidate 5 were:

  • Security keys for sessions
  • Support for XML Inclusions (XInclude)
  • Syntax for mutually exclusive message elements
  • The proposal is following the technical standards review process described in the document found here:

    This release candidate now enters a public comment period in which public review and feedback is encouraged. The public comment period will run for a period of 90 days beginning on the 20th of September 2019.

    Please post feedback, comments, and questions as replies to this discussion thread.

    Good day,

    Here is my feedback.

    1. Is there a need to include <documentation> elements into <annotation> elements? Wouldn’t it be much simpler to get rid of <annotation> elements?

    2. Is there a need to define an id attribute for each <codeset> and each <code> element? It seems redundant with the name attribute which is already an identifier. This comment may apply to other elements (message, for example).

    3. In <field> there is a type attribute which sometimes refers to a <datatype> name or a <codeset> name. Is it possible to replace this attribute by datatype and codeset attributes to make it clear what it refers to?

    4. <fixr:field added="FIX.2.7" id="48" name="SecurityID" type="String" discriminatorId="22">
      What is the benefit to specify discriminatorId? How is the domain of SecurityID specified depending on values of tag 22? Also it does not work for PartyID which could depend on both PartyIDSource and PartyRole.

    5. <fixr:unique><fixr:fieldRef id="75"/></fixr:unique>
      It is interesting to be able to specify the uniqueness of a field. However I’m not sure if it could always be specified with field references. For example, how to specify that ClOrdID is unique per day if tag 75 is not used? Could we consider having a <documentation> element to describe the uniqueness? <fixr:unique><fixr:documentation>Unique per day</fixr:documentation></fixr:unique> (it would not mean that it is unique globally however)

    6. <group> element name sounds ambiguous and similar to what a <component> is. Shouldn’t it be called <repgroup> instead or something like that?

    7. <fixr:message msgType="8" name="ExecutionReport" scenario="traded"> <fixr:structure> <fixr:componentRef id="1024" scenario="base">
      In my opinion fieldRef/groupRef/componentRef shouldn’t have to specify a scenario attribute. They should use the same scenario as the one of the message where they are included.
      From examples, scenario in fieldRef/groupRef/componentRef seems only used to specify the base scenario when the message scenario is not defined for the referenced field/group/component.
      Could the base scenario be the default scenario without having to specify it? (actually the default referenced element should be the one which defines no scenario if the element corresponding to the message scenario does not exist)
      On the other hand all tags are repeated in all messages for different scenarios except a few ones. Would it be possible to inherit from the base message and to only define tags related to the scenario? For example, to define an abstract execution report with tags common to all scenarios and to define execution reports for each scenario by only defining specific tags (LastPx for trades, LeavesQty=0 for cancellation, etc).
      Another approach which is the current approach for FIX repository would be to have one single execution report definition (without scenarios) and to specify a scenario on each field reference:
      <fixr:message msgType="8" name="ExecutionReport"> <fixr:structure> <fixr:fieldRef id="151"> <fixr:fieldRef id="151" scenario="cancel" value="0">

    8. <fixr:numInGroup id="683"/>
      Could it be an attribute (id?) of the group element instead?

    9. <fixr:fieldRef id="22" presence="constant" value="1"/>
      Isn’t the value attribute the same as the assign element?

    10. I agree that added, updated and other similar attributes could be isolated to a sub-element.

    11. It could be interesting to know what tags can be modified by a replace request.

    Regards,
    Xavier.

    @xavierbruyet, thanks for your excellent comments. I’ll try to answer as many questions as I can.

    1. The Orchestra schema annotation element follows the annotation format in XML Schema. An annotation provides one collection to iterate multiple documentation (or appinfo) elements. A documentation may be qualified by purpose: summary / elaboration / example, etc. Also, multilingual documentation is supported with language code.

    2. Generally, numeric IDs are more reliable as key fields since there are no issues of character sets, capitalization, or simple misspellings.

    3. A datatype is context-free data domain. Conceptually, a code set is a kind of datatype in which the data domain consists of a finite set of valid values. For some fields, the domain is a code set, for others it’s not. I’m open to suggestion for how to improve the XML schema to convey that concept.

    4. The relationship between SecurityID and SecurityIDSource was always explained in FIX descriptions, but the goal of Orchestra is make everything machine readable. Conceptually, it is a discriminated union, also called a variant, allowing different data domains depending on the discriminator. One kind of security ID might be numeric while another kind follows a certain character pattern.

    5. A fieldRef that has a uniqueness rule can have an annotation, but again, we’re trying to make things as machine readable as possible. If unique key does not correspond to a standard FIX field, one approach would be to create a user defined field for the purpose. Other suggestions are welcome.

    6. The default scenario is “base”. Some examples make it explicit, but it is not necessary.
      <xs:attribute name="scenario" type="fixr:Scenario_t" default="base">

    The original draft of the scenario scheme did exactly what you suggest about keeping common fields in a base scenario and inheriting that it into other scenarios. However, other members of the working group considered that confusing and would rather have all scenario contents listed explicitly, even though there is a lot of redundancy.

    1. The numInGroup tag was also originally an attribute of the repeating as you suggest. However, making it an element allows it to refer to the fieldRef type and gain all its possible attributes.

    2. An assign element need not be a constant. It can contain an expression that performs a calculation based on other fields, for example.

    3. We considered alternatives to express the pedigree of message elements. However, so far we have simply retained the same attributes as FIX Repository.

    4. This is an application question outside the scope of the Orchestra standard.

    Good day,

    Thank you for your answers and clarifications. Here is some follow-up.

    1. My points about id are:
    • identifiers are not really unique (only unique per element and per scenario)
    • identifiers don’t refer to anything known by a human reader (so it is impossible to read a FIX orchestra file without a specific viewer). Maybe the reason why types don’t refer to identifiers? (Are codeset names reliable?)
      <fixr:field type="ExecInstCodeSet">
      <fixr:codeSet id="18" name="ExecInstCodeSet" type="MultipleCharValue">
    • identifiers are very confusing since they sometimes refer to a protocol data, sometimes to nothing.
      For tags, id is the tag id as expected: <fixr:field id="1" name="Account">
      For messages, id is not the message type (as I would expect): <fixr:message id="9" name="ExecutionReport" msgType="8">
      For repeating groups, id is not the cardinality tag (as I would expect): <fixr:group id="1012" name="Parties">
    1. In our application, I think we will call it “validity” since this is the purpose of datatype and codeset to define the validity domain and it will avoid to have an attribute which could refer to two different classes.

    2. Could you provide me with an example of discriminatorId definition for PartyID which depends on PartyIDSource and PartyRole? Could you also explain what a machine can do with this attribute? How does the machine know in which case “security ID might be numeric while another kind follows a certain character pattern”?

    3. What is the difference between these two definitions?
      <fixr:fieldRef id="22" presence="constant" value="1"/>
      <fixr:fieldRef id="22"> <fixr:assign>1</fixr:assign> </fixr:fieldRef>

    1. “identifiers don’t refer to anything known by a human reader” - true, but the intention is to be machine readable rules of engagement. Applications and documentation generators can render them humanly readable.
      I don’t follow what you mean by “cardinality tag”. Please explain.

    2. The first example with presence=“constant” makes the field a permanent value. In some encodings, such as SBE, constants need not be sent on the wire since they are provided in metadata. In the second example with “assign”, the field is also set to a constant value, so the effect is almost the same. However, assignment expressions are not always constant. For example, an expression for an amt (monetary amount) field can give a formula of qty * price.

    “Cardinality tag” means “numingroup tag”.

    I see. Yes, I am aware that some data dictionaries identify a repeating group by its NumInGroup tag. However, Orchestra does not do that for two reasons.

    1. A component always had a unique identifier in FIX Repository, distinct from its NumInGroup field.
    2. Many FIX encodings, including FIXML and SBE, do not have a NumInGroup field as part of a repeating group, but have other structures to convey an array of records.
    1 Like

    Can we make id optional and add the possibility to refer to fields/groups/components by name? So we could define messages like this:

    <fixr:message msgType="8">
        <fixr:structure>
            <fixr:fieldRef name="ClOrdID"/>
            <fixr:componentRef name="Instrument"/>
            <fixr:groupRef name="Parties"/>
    

    Further to last catch-up meeting, I’ve written a small example which shows different ways to define scenarios. The “trade” scenario is defined by duplicating message and codeset. The “ack” scenario is defined by duplicating field and code.

    (I used name instead of id for readability)

    <!-- default execution report definition -->
    <fixr:message msgType="8">
        <fixr:structure>
            <fixr:fieldRef name="ClOrdID"/>
            <fixr:fieldRef name="ExecType"/>
            <fixr:fieldRef name="CumQty"/>
            <fixr:fieldRef name="CumQty" value="0" scenario="ack"/>
        </fixr:structure>
    </fixr:message>
    
    <!-- execution report for trades -->
    <fixr:message msgType="8" scenario="trade">
        <fixr:structure>
            <fixr:fieldRef name="ClOrdID"/>
            <fixr:fieldRef name="ExecType"/>
            <fixr:fieldRef name="CumQty"/>
            <fixr:fieldRef name="LastQty"/>
            <fixr:fieldRef name="LastPx"/>
        </fixr:structure>
    </fixr:message>
    
    <fixr:field name="ClOrdID" type="string"/>
    <fixr:field name="ExecType" type="ExecTypeCodeSet"/>
    <fixr:field name="CumQty" type="Qty"/>
    <fixr:field name="LastQty" type="Qty"/>
    <fixr:field name="LastPx" type="Price"/>
    
    <!-- default code set for exectype -->
    <fixr:codeSet name="ExecTypeCodeSet" type="char">
        <fixr:code value="0" scenario="ack"/>
        <fixr:code value="4"/>
        <fixr:code value="5"/>
    </fixr:codeSet>
    
    <!-- code set for exectype for trades -->
    <fixr:codeSet name="ExecTypeCodeSet" type="char" scenario="trade">
        <fixr:code value="F"/>
        <fixr:code value="G"/>
        <fixr:code value="H"/>
    </fixr:codeSet>