XML Definitions for FIX 4.0 - 4.4 for engine developers

, ,
1

Imported from previous forum

2

[ original email was from Jim Northey - jnorthey@lasalletech.com ]
Create standard XML representations of the FIX 4.0 - 4.4 specification for developers of FIX engine products to more readily generate their parsers.

Most firms use either the FIXimate HTML or worse still the Microsoft Word document as a starting point for generating their parser.

The proposal here is to create XML document versions of the spec that can then be used by FIX engine vendors (most likely transformed) for their own parser generators.

It makes sense for us to have an easy to use format that has been debugged and checked and is consistent with the specification, as opposed to forcing industry participants to create their own.

With the complexity of the FIX 4.3 specification, it is much more difficult to use the word document for parsing.

3

Jim,
ISO XML ( 15022 )WG creates an XML schema at the end of the analysis process. Is the TC contemplating a similar idea for "classical Fix?" Can you clarify?

Best Regards,
John Sabini

> Create standard XML representations of the FIX 4.0 - 4.4 specification for developers of FIX engine products to more readily generate their parsers.
>
> Most firms use either the FIXimate HTML or worse still the Microsoft Word document as a starting point for generating their parser.
>
> The proposal here is to create XML document versions of the spec that can then be used by FIX engine vendors (most likely transformed) for their own parser generators.
>
> It makes sense for us to have an easy to use format that has been debugged and checked and is consistent with the specification, as opposed to forcing industry participants to create their own.
>
> With the complexity of the FIX 4.3 specification, it is much more difficult to use the word document for parsing.
>
>
>

4

Jim,

I have implemented a FIX engine that is mostly generated from a customized QuickFix Fix 4.2 XML file via custom XSLT style-sheets.

I understand there may be an an official FIX spec in an XML file in the future, and I have some ideas for what I’d like to see in such a file.

  1. Add an attribute (e.g. @other_values_allowed="Y") to fields like #22 and #27, where user-defined values are allowed to be sent in addition to the defined values.

    <field number="22" name="SecurityIDSource" type="STRING" other_values_allowed="Y">
    <value enum="1" description="Cusip"/>
    <value enum="2" description="Sedol"/>
    </field>

  2. Add an attribute (e.g. deprecated="4.2") to fields that are no longer used.

    <field number="24" name="IOIOthSvc" type="CHAR" deprecated="4.2"/>

  3. Make every group have a mandatory first (starting) field. Add an attribute to that field (e.g. starts_group="Y"), or update the specification to specify that the first field in the group is always mandatory. Otherwise you have to depend on duplicate fields in a group to know when the next group begins. I would do it even for groups with only one field.

    <group name="NoIOIQualifiers" required="N">
    <field name="IOIQualifier" required="Y" starts_group="/>
    </group>

    <group name="LinesOfText" required="Y">
    <field name="Text" required="Y" starts_group="Y"/>
    <field name="EncodedTextLen" required="N"/>
    <field name="EncodedText" required="N"/>
    </group>

  4. Make every field in the group have its own "required" attribute, that is valid within that group and below.

    <group name="NoMsgTypes" required="N">
    <field name="RefMsgType" required="Y"/>
    <field name="MsgDirection" required="Y"/>
    </group>

  5. Come up with a scheme to identify all conditional fields within a message, and their conditions. For example, in a MarketDataRequest message, the PutOrCall and StrikePrice tags are mandatory if SecurityType is equal to "OPT". I think that this is the single most important addition to the XML file that can be made to help generate correct Fix engines.

Thank you,

Dmitry Volpyansky