[repository schema] Increase maximum length of MsgType attribute

[kleihan]

The current definition of message types is based on the needs of FIX, i.e. one or two characters long:

    <xs:simpleType name="MsgType_t">
        <xs:restriction base="xs:string">
            <xs:minLength value="1"/>
            <xs:maxLength value="2"/>
        </xs:restriction>
    </xs:simpleType>

They are intended as human-readable and well-known shortcuts for message names, e.g. "D" for FIX NewOrderSingle(35=D) or "8" for FIX ExecutionReport(35=8). Non-FIX protocols may have longer acronyms, e.g. SEC-CAT uses 5 characters to identify events and related messages, e.g. "MENO" for "New Order" and "MENOS" for "New Order Supplement".

The proposal is to still set the maximum length (to maintain the original intention of the attribute) but to change it from 2 to 6.

[patricklucas]

According to its original purpose implied by its usage in FIX, I think increasing the max length of MsgType_t to 6 makes sense.

After making that change, however, I would like to start another discussion about further codifying the concept of "message type determination" independently from FIX.

"Message type"/"MsgType" is not a fully-defined concept in Orchestra, and in fact it is fully implicit how an implementation could use the msgType attribute on messages to actually determine the type of a message. For example, in FIX:

• There is a code set MsgTypeCodeSet, the "value" of each code within the code set corresponds to the msgType attribute on message definitions
• There is a field MsgType, of type MsgTypeCodeSet, in the StandardHeader component, included in every message, which an implementation can use (by matching its string value to the msgType of defined messages) to identify the type of a message

However, this behavior is not actually codified in Orchestra (nothing "marks" the MsgType field in every message as indicating the message type, apart from its name).

My claim is that "MsgType" is a FIX, not Orchestra concept, even with encoding-specific handling requirements, and that Orchestra needs a general mechanism for expressing the set of message types and how to determine the message type for any given encoding.

I suggest that for the moment, we apply the change to increase the max length of the msgType attribute, as it is a very lightweight change, and then open a separate discussion about the future of message type determination in Orchestra.

[kleihan]

@patricklucas I agree that this is a separate discussion. The topic is related to #166, even though it is related to a situation with multiple scenarios. The rule to use MsgType(35) in the message to find the msgType attribute in the Orchestra XML file is specific to FIX. To make it generic for Orchestra, FIX Latest could add a <fixr:when> element to each message definition, for example

<fixr:message msgType="D" name="NewOrderSingle" category="SingleGeneralOrderHandling" added="FIX.2.7" id="14" abbrName="Order">
    <fixr:structure>
    </fixr:structure>
    <fixr:when>MsgType="D"/>
</fixr:message>

Additional attributes can be added to the <fixr:when> element in case of multiple scenarios for the NewOrderSingle message.