FIXML
A Markup Language for the FIX Application Message Layer

Table Of Contents

    Executive Summary
    Objectives
    Implementation
    Scope of the Working Group
    Future Directions
    Next Steps
    Conclusion

Executive Summary

The FIX Protocol, as a cooperative effort of principal asset management and brokerage firms in the US and Europe, has evolved to an effective standard for real-time electronic communication. Shortened settlement dates, straight through processing, and increased interest in electronic connectivity has positioned FIX to be major component of real-time electronic trading systems. A strong presence in the U.S. has led institutions in Europe and Asian to now look to the FIX protocol as a means for electronic connectivity.

An important factor in FIX's success has been its flexibility and extensibility at the application message level. The standard is not controlled by one single entity and is flexible enough to be tailored to an institution's individual business requirements. FIX remains vendor neutral and avoids over-standardization, preferring to leave these decisions to the participating firms. This flexibility has come at a cost.

FIX's flexible tag-value message format is a double-edged sword. It imposes no structural constraints on a message, so all but the most trivial validation must happen at the application level. The increasing number and complexity of FIX application messages creates ambiguities that are handled differently by diverse systems.

This paper proposes an evolution of the FIX application messages to FIXML, a structured, validated Extensible Markup Language (XML) derived grammar that is encapsulated within the standard FIX message. This format leaves the FIX session handling intact and minimizes the impact to existing implementations. As an XML-derived language, FIXML messages can be validated by standard parsers and take advantage of a flexible message structure.

XML can also allow us to add further functionality to the FIX protocol without causing further version fragmentation. This is going to be extremely important to the future success of FIX as we try to deal with competing demands for new functionality, products, and geographic regional support. Also, it will help with Straight Through Processing by allowing us to pass some fields directly through to downstream systems.

The World Wide Web Consortium (W3C) is the driving force behind the design of XML. XML's main features include extensibility, ease-of-use, and dependability. Since XML's release, there has been a host of custom data exchange formats based on XML primarily because of its ability to represent structured data. XML tools are widely available on the web and most major software vendors will be providing XML support in their next releases.

XML is a text-based format very similar to HTML. XML documents contain elements that consist of start tags and end tags. Similar to HTML, XML holds content between the two tags. However, unlike HTML, XML allows an unlimited set of tags to describe the structure, meaning, and layout of the content.

Valid XML messages need to reference a Document Type Definition (DTD). DTD's list elements and attributes and how they interact with one another. The DTD details valid message content and structure similar to the FIX specification.

Objectives

• Session and application layers that evolve independently
  The separation of application and session layers creates opportunities to break away from the traditional methods of implementing FIX. Session and security levels can develop unconstrained without affecting application level messages. A new security model could be embraced or the session layer could be implemented using off-the-shelf technology.
• Improved communication
  A DTD-based protocol language (one based on XML) offers improved communication over written documentation alone. This claim comes from the global and growing knowledge base surrounding DTD-based protocols. Simply put, a DTD-based protocol eliminates ambiguity through a formal language and allows more robust and flexible software implementations.
• Improved evolution and extensibility
  A DTD-based language provides a better communication model for software and humans. One can quickly evolve and extend the FIX protocol while protecting the value of previous works.
• Structure and content validation
  DTD-based structural and content validation provides many benefits, but the biggest benefit is that DTD-based structural and content validation eliminates imprecision over current procedural-based software implementations. This allows the FIX community to focus on more important functional and business objectives instead of mundane technical issues.
  Despite the unresolved issues surrounding content validation as it relates to XML, a path can be chosen and recommended by the parties developing the FIXML specification today. Content validation must be included as a required goal, otherwise it seems like a step backwards, or at best, no level of improvement.
• Evolutionary not revolutionary
  XML offers an evolutionary model for future improvements to the FIX protocol, allowing the protocol to evolve naturally and in a controlled way. This ultimately allows the FIX community to satisfactorily address their business.
• Reduce duplication of effort
  XML is becoming widely used and well-respected in the software industry. Basing FIX on XML will provide commonality with other initiatives outside the FIX community and help to reduce duplication of effort in achieving mutual goals. In forums such as EDI, S.W.I.F.T., OFX, and ISITC, dictionaries are being built that describe the varieties of price, quantity, security, etc. XML allows these groups to share results and save effort by leveraging each other's work. Over time, this may also establish a basis for convergence and interoperability of these various message standards. The ultimate benefit will be a common data dictionary for the financial community that helps pave the way for straight through processing.

FIXML is the FIX Markup Language for application messages. It is an XML-derived language, encompassing a series of Document Type Definitions (DTDs) which define the formal representation of FIXML messages. These DTDs will be maintained and versioned in the same manner as the FIX specification.

Since FIXML is an XML-based language, it can be parsed/validated by any of the widely available XML parsers, and is positioned to evolve with the XML standard in areas such as datatype validation.

The FIXML DTD ensures consistent parsing of messages and removes ambiguities related to conditionally required fields, nested elements, etc. DTDs can be divided into hierarchical subsections that are independently versioned.

FIXML's structured, hierarchical message formats facilitate the expression of relationships between various pieces of data. It provides contextual data grouping and sub-grouping, reducing the total number of elements in the grammar and supporting previously difficult concepts such as conditionally required and repeating groups of fields.

The initial implementation will involve separating the FIX application from session layers. A FIX session as stated in the FIX Protocol Specification is a bi-directional stream of ordered messages between two parties within a continuous sequence number series. The session layer of FIX involves establishing and maintaining that connection and encompasses administrative messages like Logon, Logout, Heartbeat, Test and Resend Request, and Reject. Application messages involve the exchange of business related messages like Indications of Interest, Quotes, Orders, Execution Reports, etc. Both administrative and application level messages require a standard header and trailer that serves as an envelope for the message content. This header and trailer envelope are consider part of the session layer.

The separation of application and session layers will require the creation of a small number of additional fields contained in the FIX header. This approach is desirable for two important reasons:

1. Since the additional field is optional, this approach will not break existing FIX implementations.
2. By encapsulating the FIXML application message within a standard FIX field, we achieve a separation between the application and session components of FIX, allowing each to evolve at its own pace.

The XML Working Group will address the following:

1. Develop the valid syntax for FIXML messages. This will include the creation of Document Type Definitions or DTD's. DTD's define element names and attributes and describe when elements occur and how they are used. The goal is to equate FIXML to existing FIX formats.
2. Explore the use of shared Internet dictionaries as possible repositories for our DTD's and other definitions and components as needed.
3. Create a framework for a FIXML implementation. A separate "specification" document will detail the actual message formatting and elaborate on the DTD's and methods.
4. Design a working implementation as a "proof of concept".
5. Create a separate position document that supports FIXML working with other standards bodies like S.W.I.F.T., OFX, etc.

Future Directions

As previously stated, the separation of the FIX application and session layers will allow the two to evolve independently. As the FIX protocol continues to become more widely accepted, the potential to reach an expanded list of counter-parties will require the reliance on expensive leased lines or third party network solutions. An application server that understands XML could act as the catcher's mitt for an existing FIX engine. Connecting in the mode of current web-based applications over the Internet negates the need to maintain hundreds of individual FIX sessions.

Databases and word processing applications will also soon accept XML as a valid format. Existing databases or word processing software will read FIXML message log files.

XML Namespaces (a W3C sanctioned work-in-progress) provide an infrastructure that could be used to maintain user-defined, or custom fields. There would no longer be a need to depend on members to submit user-defined fields to prevent collisions. Each member could have a unique XML namespace, and introduce as many new fields as needed.

The DTDs of XML and XML derivatives do a good job at providing structure for data, but are weak when it comes to specifying and enforcing data typing of the data itself. The current FIX specification provides a strong notion of data typing for each field. Several proposals (as opposed to W3C sanctioned work-in-progress) addressing this issue have been submitted to the W3C, including a proposal from Microsoft and others called XML-Data.

Next Steps

Some future items for consideration include the following:

• A formal presentation to the FIX Technical Committee.
• Approval of FIXML to be included in a future FIX release.
• Investigate upcoming features in XML v2.0 for better integration with FIXML requirements.
• Coordinate efforts with other standards bodies and FIX working groups.

The redefinition of an existing standard is nontrivial and will not be embraced without sufficient reason. This white paper has attempted to elaborate on some of the benefits of FIXML, an XML-based specification for the FIX application layer. FIXML provides message format validation, easier programming due to the wide availability of parsers, a cleaner and more expressive structure, and much-needed alignment with existing standards. This committee believes that FIX is outgrowing its current approach to message definition, and therefore must move to a more robust standard or face implementation inconsistencies and fragmentation. The implementation approach outlined here enables gradual migration to the FIXML standard without compromising existing FIX solutions.