A December 2000 from The Financial Information Services Division (FISD) of the Software and Information Industry Association (SIIA) describes the formation of an XML for Market Data Working Group. The XML Working Group will attempt "to consolidate industry efforts to define the parameters of the XML for market data discussion (i.e., the fields needed to describe a security and its price). ['Fields' mean (e.g.) Identifier, ISIN, CUSIP, Last, Open, Best Bid, Best Ask, Close, Next Bid, Size, Maturity Date, Coupon, Yield, Call/Put, Strike Price, etc.] If the industry is able to unify around a common size and scope definition, FISD is interested in (1) serving as the facilitator of the discussion to create a standard, (2) supporting and maintaining the standard as a permanent home and (3) coordinating with the other major financial industry XML standards efforts such as NewsML (news), FpML (derivatives), IRML (investment research) and XBRL (business reporting) as appropriate." According to the announcement, "user firms are interested in extracting information from a vendor's data feed ('vendor' defined as any information provider including exchanges and contributors) into common desktop applications. The requirement is not for an individual trader who wants access to multiple sources of data, but rather for distributing information to disparate systems throughout the organization. For that, the users need a standard protocol and common data format. Jeremy Sanders (Merrill Lynch) envisions using the XML standard primarily for end-of-day and intra-day snapshot application feeds rather than for streaming data."
An antecedent to this effort is a draft authored by Bridge, which "describes an implementation of XML to be used for distributing financial information. A primary goal of this implementation is to be flexible enough to carry data from any financial market data vendor, including, but not limited to, exchanges, brokerage houses, banks, and information vendors." Background to the MDML XML specification is described thus: "While all market data vendors carry largely overlapping sets of data, they have all developed different data models, protocols and symbologies. Each vendor supplies a highly specialized application set for making the best use of their data. Extracting information from a vendor's data feed into common desktop applications can only be done with custom software. A class of products called integration platforms has been developed to ease this problem. Integration platforms convert vendor data into their own proprietary models so their specialized application set can make use of data from many vendors. While this solves the immediate problem of a trader who wants access to multiple sources of data through a single desktop, it doesn't solve the larger problem of distributing information to disparate systems in an organization... Most if not all market data vendors have solved the problem of data modeling by developing simple models which allow them to carry an ever increasing variety of information without making changes to their infrastructure or simple display applications. There are two broad classes of representation, which here will be referred to as pages and records. Pages are unstructured collections of data formatted for display in a fixed sized window. A record is a set of properties each containing a piece of information related to that record. Records representing different types of securities (i.e., Japanese Government Bonds and Dollar Yen Swaps) will contain different sets of properties. Even when vendors' wire protocol represents information in fixed sized structures, it is still conceptually sets of properties. Pages themselves can be, and often are, distributed as sets of properties - containing the page's width, height, text, color attributes in separate properties. Other types of information can be represented as sets of properties, but tend to have more complex request parameters, and usually contain repeating rows of data. Examples are news headlines, historical trades, and options and futures chains. In order to represent this information in XML, MDML defines a property and its attributes, as well as conventions for assembling properties into the objects that are returned from queries on a vendor's data feed. MDML also defines a convention for representing repeating rows of data. In order to improve access to the information, MDML defines a default set of object types with default properties, as well as request structures for them. The set of object types, and their properties, is extensible so a market data vendor can include its own value-added information and differentiate its products. This specification includes examples of MDML, but not schemas or DTDs. Examples are much better at conveying the structure and use of an XML. Once MDML is finalized, schemas and/or DTDs will be published, separate from this document, to allow parsers to validate MDML... MDML tags [used in the draft specification] are defined to be in the MDML namespace, which is uri:xml.com.bridge/mdml-1.0. Appendix 2, 'Market Data Control Set', lists the elements and attributes that are used by MDML."
[January 05, 2001] Dow Jones MDML Overview and XML DTD. "Dow Jones MDML is an XML application, and is described by an XML-compliant DTD. The root element is called mds-results, and represents a transaction package. It has attributes that represent criteria specified at the beginning of the transaction, and other information that might be needed to complete it. Some attributes are geared toward a web server request, such as 'remote-user' and 'http-user-agent'. Others are used to pass on information about the process that created the MDML data, such as 'creation-date', 'error-condition', 'error-code' and 'route'. The mds-results element has container elements that each hold a different type of data. For example, some of the children of mds-results are instrument-set, portfolio-set, headline-set and earnings-report-set. Keeping each type of data in a separate container, and making each container optional, makes the DTD very modular. This allows placement of any combination of data into one MDML document, or just one data type. Data can be matched up between the different containers using key values, such as ticker symbol, or an identification scheme like SEDOL or ISIN. In general, all data are represented in an object-oriented manner, with elements representing objects (e.g., purchase, instrument, headline) and attributes representing properties of the objects (e.g., number-of-shares, news-symbol, headline-text). This content-less model works well for raw data and reduces hierarchical complexity. The DTD contains specific markup vocabularies for many different types of market data: (1) corporate earnings; (2) equities; (3) bonds; (4) indexes; (5) options; (6) mutual funds; (7) currencies; (8) commodities; (9) U.S. Treasuries. It also has structures for holding lists of headlines, which may be related to a company in an instrument set. It is designed for easy expansion to cover other instruments and markets. WSJ.com developed the Dow Jones Market Data Markup Language in 1999 to describe market data, symbology and portfolio information on the web site. Later WSJ.com began using the XML-based DTD as an interchange format with an internal database of corporate earnings, and with Factiva, the electronic archival service that is a joint venture of Dow Jones and Reuters Inc."
