[ OVERVIEW ]          [ STRUCTURE/PARTICIPANTS ]          [ MDDL DOCUMENTS ]          [ LINKS ]
[ DISCUSSION ]             [ JOIN MAILING LIST ]             [ MEETING SCHEDULE ]          [ NEWS ]
 

Market Data Definition Language (MDDL) Technical Committee Mar. 22 Meeting

April 2, 2001


Organizations Present

Associated Press, Bear Stearns, Bloomberg, Bridge, Dow Jones, FISD, Fidelity, FinPortfolio, Goldman Sachs, Lehman, Merrill Lynch, Morgan Stanley, Multex, Reuters

Meeting Objectives

The primary goal of the meeting was to review the architecture, structure and rules of existing financial industry XML standards/specifications in terms of their relevance to MDDL. The overall purpose is to resolve the up-front design issues related to the structure of the standard. The secondary goal was to pinpoint the user requirements for snapshot data and to ensure that the design goals of MDDL match the problem we're trying to solve with the initiative.

Next Meetings

  • March 29 -- Technical Committee conference call. 9:00am EST
  • March 29 -- Vocabulary Committee meeting. 1:00 EST at Dow Jones. Dial in available. Contact Mike Atkin.
  • April 2 -- User Specification Meeting. 2:00 - 5:00 EST on April 2 at Merrill Lynch.
  • April 19 -- Technical Committee Meeting. Location to be confirmed shortly.

Specification Review

XBRL: Extensible Business Reporting Language, http://www.xbrl.org

  • Good example of DTD taxonomy
  • Attribute-oriented format
  • Potential model for organizational structure and logistics
  • They have experience with cross-domain development -- common elements across domains particularly for fundamental data
  • XBRL does cross-country comparison, MDDL will need to do cross-product comparison -- could be a model to emulate
  • Vocabulary link -- overlap of data elements and cross-linking of terminology

MPEG 21

  • Audio/video format
  • Primary interest is in digital rights management
  • Might be useful if MDDL is going to consider more than data specification issues such as protocols, security, rights, etc.

IRML: Investment Research Markup Language, http://www.irml.org

  • Defining an open standard for exchange or research information from an analysts perspective
  • Primary relevancy is on the packaging of multiple sources into a common standard
  • Good example of cross-linking of common fields -- might offer approach on how to ensure that common fields are aligned
  • Vocabulary link -- unique security identification

RIXML: Research Information Exchange Markup Language, http://www.rixml.org

  • Open standard for investment and financial research
  • Expected to by published April 4
  • Primary focus is on "document meta data" -- i.e. format independent -- focus on the content of the document
  • Relevancy is approach to meta data and data extraction approach (i.e. how to mine specific financial information from a general document) -- format-independent data mining

FIXML: Financial Information Exchange Protocol, http://www.fixprotocol.org

  • messaging standard developed specifically for the real-time electronic exchange of securities transactions
  • Protocol-related (MDDL is data related)
  • Might be some data element overlap
  • Vocabulary link -- unique instrument identification

MarketsML: Markets Markup Language

  • Internal Reuters initiative to create a framework for integrating information from multiple XML formats
  • Internal initiative to solve problems of data comparison
  • Very early stages of development
  • Content focused, not architecture/tag focused

FpML: Financial Products Markup Language, http://www.fpml.org

  • Transactional standard (not directly relevant)
  • Very unique architecture for defining elements. Very few attributes, mostly elements
  • Could provide an architectural lesson for MDDL

OFX: Open Financial Exchange, http://www.ofx.net

  • Focus is on personal finance
  • Not relevant to Technical Committee but might have a vocabulary link

MDML (Dow Jones): Market data markup language, http://www.fisd.net/news/0101_dowjones.html

  • Internal DTD for Dow Jones (in use)
  • Attribute-based
  • Valid architectural approach to explore

MDML (Bridge): Market Data Markup Language, http://www.fisd.net/mdpolicy/1100_mdmlspec.pdf

  • Draft market data specification for Bridge
  • Valid architectural approach to explore

SWIFT: http://www.iso15022.org, http://www.swift.com

  • Message format for transactions based on ISO 15022 Data Dictionary
  • Vocabulary link -- unique security identification
  • Proprietary design based on SWIFT message format, not relevant to architectural approach

NewsML: News markup language, http://ww.iptc.org

  • Good generic DTD for identifying third party vocabulary/lists
  • Useful model for cross-list management - makes it easy for vendor extraction by separating the mechanism of access from the content.
  • Architectural relevancy is as a bridge between standards including vendor specific content (list)

Maintenance

Maintenance of MDDL cross-reference is a core issue. The vocabulary list is huge and dynamic. This is a critical question for both the Vocabulary and Steering Committee. Must be able to answer the question of who is going to fund maintenance.

Security Identification

Unique security identification is the common denominator among all financial XML initiatives. This is also the link between the technology and vocabulary committees. The unique identification of "things" must be addressed at the outset of this work!

XML Tool Vendors

MDDL participants want us to expand the reach of the activity to include the XML tool suppliers including Oracle, TIBCO-extensibility, Sunsoft, Microsoft, and IBM.

User Application Requirement

There is broad consensus among FISD members that user applications are the key driver of the MDDL initiative. As such, both the Technical and Vocabulary Committees are interested in the development of user case examples on how MDDL will be applied in real-world situations. User firm participants agreed to coordinate their efforts toward the development of a functional user requirement.

The operating assumption is that user firms distribute a significant amount of pre-defined snapshot data to a wide variety of database applications. As such they spend a lot of time and money translating market data formats and modifying applications for internal communication. The basis of the user requirement is for MDDL to:

1. Support multiple vendors

2. Common communication interface to various vendors

3. Common request format for different vendors with standard request types and field names

4. Standard snap request by vendor specific instrument names or by vendor independent ISIN, exchange code, instrument type (or any combination)

5. Dynamic (user pull) snapshot data elements to be included in request/response

6. Allow requests for vendor specific fields

7. Allow requests for vendor specific services

8. Each request must contain user, application and host information. Each request to a service must be made with user information to allow entitlement checking or entitlement checking must be done by our application.

9. For all standardized requests, response must use standard field names

Among the most common fields required for snapshot applications are: bid, ask, last, previous close, high, low, exchange, previous close date, cumulative volume, trade time, open and close.

MDDL Functional Specification

OUTLINE (draft 3/19/01)

Preface (and acknowledgements)

Section 1. Introduction

Section 2. Scope

Section 3. Executive Summary

Section 4. MDDL Structure

4.1 Design goals (paradigms to which we have adhered)

  • Hierarchical versus flat
  • Elements versus attributes
  • Extensibility
  • Name Space
  • Request/Response mechanisms and brief/full content
  • DTD versus Schema
  • Conformance and Compliance

4.2 Vocabularies (market categories, domains, classes; data definitions or controlled lists) http://www.fisd.net/reports/xml_030501datad.xls

4.3 XML models (concepts generated or borrowed from existing work)

4.4 Elements

4.5 Attributes

    Section 5. Relation to Other XML Initiatives

    The MDDL domain, as regards … (list needs to be fleshed out)

    XBRL
    FIXML
    IRML / RIXML
    SWIFT / ISO specs
    FpML
    NewsML / NITF …
    SOAP

    Section 6. Deliverables

    6.1 Discussion of Appendices

    6.2 Description of Website (www.mddl.org?)(w/contact links)

    6.3 Maintenance Committee Organization and Change Process

    6.4 Reference to API Tools and Validation Software

    Section 7. References / Bibliography

    Appendix A Technical Specification

    DTD and/or XML Schema (examples and diagrams as needed)

    Appendix B Technical Documentation (to support Appendix A)

    Appendix C User Documentation

    Implementation Guidelines

    Examples, Diagrams

    Appendix D Data Dictionaries (from Vocabulary Committee)

    Appendix E Vocabularies (from Vocabulary Committee)

    Design Comparison of NewsML and NITF

    This is an example of ways to define the intended scope of MDDL:

    Category

      • NewsML and NITF are both in the news industry domain (versus auto, aerospace, etc.)

    Structure

      • Both are DTDs (as opposed to schema)

      Nature of Application

        • NewsML is a wrapper
        • NITF is a text format

      Content Focus

        • NewsML is database centric
        • NITF is document centric

      Summary

        • NewsML is a container for multiple objects of any data type that make us a news story
        • NITF is used to mark up news articles -- within or independent of NewsML

      Navigate

      A simple diagram would show NewsML as an outer container for discreet objects, which may be test, graphic, photo, audio or video. Alternate versions of any object may exist. A test object typically would be labeled as being NITF. The diagram could have visual links to data providers (such as companies or stock exchanges) and to customers (such as news aggregators).

       

       

       

       

       



      Copyright ©2001, The Software & Information Industry Association.
      SIIA's Privacy Policy and Use Agreement.
      All rights reserved.