Version 2 XML schema proposal

[donmendelson]

I am making this proposal to get feedback from the community... SBE version 1.0 is a FIX final technical standard (as well as a forthcoming ISO standard), and therefore cannot change. However, we can consider improvements for version 2.

N.B. Nothing in this proposal is intended to change the wire format of SBE, only the metadata that describes a message schema.

The proposal is to converge the the SBE XML schema with the FIX Orchestra repository schema.

The commonalities between the two schemas are:

• Message layouts
• Datatypes
• Code sets (aka enumerations)

However, the Orchestra schema has several additional features (not all need be used by all users or for all use cases):

• A field data dictionary -- Orchestra lists all field types independent of the messages that contain them. This provides one place to describe their semantics and make sure they are unique. OrderQty represents the same concept whether it is in an order message, a cancel message, or an execution message.
• Components -- a component is a message fragment that is defined once but can be reused in any number of messages. For example, Instrument gives the attributes of a traded security. It can be included in a message by just inserting a reference to the component. The benefit is that all instances are identical, even if the component has changed. Thus, copy-and-paste errors are avoided.
• Repeating groups -- like components, makes groups reusable in multiple messages.
• Message scenarios -- a scenario qualifies a message type for a specific use case. That is, a fill event may have a slightly different message layout than an order booked event, but they are both considered execution reports. In SBE, they would be separate templates but have common naming in metadata.
• Workflow -- relationships between message types. If I send you message A, they you might respond with X, Y or Z under different conditions.
• Conditional rules -- Orchestra has a DSL called Score to define rules. One use is for conditionally required fields, e.g. StopPx field is required if OrdType is Stop or Stop-Limit. The other use in workflow; when a certain condition applies, then respond with X, or if another condition evaluates true, then respond with Y. Score is intended to be familiar to developers of Java, C++, etc.; the expression syntax is very similar.

Moreover, several applications have been developed for Orchestra that could then be applied to SBE message schemas.

• Tablature -- an open source project that translates between Orchestra files and markdown documents. The flow is bidirectional: XML to markdown provides humanly readable documentation while markdown to XML enables easy authoring (never have to edit XML directly).
• Other open-source Orchestra demo projects published by FIXTradingCommunity
• Several projects available to FIX members, including a UI for Tablature

Orchestra already has a feature to map datatypes to multiple encodings, including tag-value, XML schema, JSON, etc. This can be done with SBE, too, but may require some small refinements.

[jimnup]

I am working on a project now where we are having to translate SBE -> Orchestra and Orchestra -> SBE. I think having a single schema that could represent multiple encodings (as Orchestra was intended and tested to be able to do) would simplify DevOps.