Package override on type

[mjpt777]

It would be useful to provide a package override on on types such at the composite type for MessageHeader. This would enable those types to be XIncluded into other schema and avoid redefinition. This allows for better organisation of SBE Schemas. The package can be used for language namespace generation.

• common-types.xml

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<sbe:messageSchema xmlns:sbe="http://fixprotocol.io/2016/sbe"
                   package="com.company.common"
                   id="1"
                   version="0"
                   semanticVersion="5.2"
                   description="Common types"
                   byteOrder="littleEndian">
    <types>
        <composite name="messageHeader" package="com.company.common">
            <type name="blockLength" primitiveType="uint16"/>
            <type name="templateId"  primitiveType="uint16"/>
            <type name="schemaId"    primitiveType="uint16"/>
            <type name="version"     primitiveType="uint16"/>
        </composite>

        <composite name="groupSizeEncoding" package="com.company.common">
            <type name="blockLength" primitiveType="uint16"/>
            <type name="numInGroup"  primitiveType="uint16"/>
        </composite>
    </types>

</sbe:messageSchema>

• included-usage.xml

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<sbe:messageSchema xmlns:sbe="http://fixprotocol.io/2016/sbe"
                   package="com.company.example"
                   id="2"
                   version="0"
                   semanticVersion="5.2"
                   description="Includes ommon types"
                   byteOrder="littleEndian">

    <xi:include href="common-types.xml "/>

</sbe:messageSchema>

[donmendelson]

Now I thinking package override would be at level of included <types> or <messages> container element (issue #94) rather than individual type or message. Agree?

[mjpt777]

That makes sense. Good idea.

[mjpt777]

I can understand the need for package on <types> however I'm struggling to see a usecase for it on <messages>. @donmendelson Can you foresee such a usecase?

[donmendelson]

@mjpt777 one scenario--common messages that are reused in multiple service offerings. They could be maintained in a separate XML file and imported through XIinclude, just as common types are. For example, FIX BusinessMessageReject could be reused in several services.

[mjpt777]

@donmendelson Thanks.