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

MDDL Position Papers on Technical Design Issues

April 30, 2001


Discussions of Positions on Technical Issues (draft 4/30/01)

Section 1. Hierarchical versus Flat Structure

Section 2. DTD versus Schema

Section 3. Conformance and Compliance

Section 4. Elements versus Attributes

Section 5. Extensibility

Section 6. Name Space

Section 7. Request and Response Mechanisms

Section 8. Documentation


1. Hierarchical versus Flat Structure

    The form of the MDDL specification can take either a hierarchical or flat structure. With relationship to XML, this can be discussed in terms of elements defined in a DTD. A flat structure specifies that all elements are siblings as children to the single root element of the document. A hierarchical structure allows some elements or groups of elements to be children of other elements or the root element creating a tree-like structure.

    The actual representation of the elements will most likely be dictated by the structure of the data as defined by the MDDL Vocabulary Committee. The MDDL Technical Committee will develop the architecture of the MDDL v1.0 standard around a hierarchical structure will the allowance that the redundant form of a hierarchical structure is, in fact, a flat structure. In this way, the technical specification can develop while the MDDL Vocabulary Committee is defining the data aspect of the specification.

2. DTD versus Schema

    As XML evolves so do the ways of defining the specification and the features it must include. Initially, the "Document Type Definition" was the best mechanism for defining the logical structure or content model of an SGML based tagged document. Experience with this system and modern enhancements to the basic DTD capabilities fostered the development of XML Schema Definition language (XSD) to allow a more descriptive way of specifying the content model while also including information about the datatypes included in the document.

    While support for XSD is not as prevalent in the marketplace as DTDs, it is quickly gaining support because of the increased functionality and extensibility it provides over the DTD. As it reaches maturity, XSD is envisioned as a better solution for new XML specification development.

    MDDL will be developed based on XSD with the constraint that it must directly correlate to a DTD. In this way, implementers can take advantage of existing tools, functionality, and understanding while still permitting the MDDL specification is positioned to extend beyond current limitations. In addition, those who have not implemented XML processing can start with XSD and use its datatyping conventions.

3. Conformance and Compliance

    The creation of an XML definition with a DTD or a schema does not guarantee that the content delivered is consistent with the authoring organization’s intentions or desires.

    Once MDDL is defined and made publicly available for general use, it may be necessary to establish guidelines and metrics for determining if an individual implementation adheres to the specification with regards to form and content. This will be essential if an implementer wishes to advertise adherence to the MDDL standard or "Powered by MDDL" related claims.

    It is conceivable that documents and scripts can be generated that will determine if an implementation is fully consistent with the letter and the spirit of the standard. However, the MDDL Technical Committee is not likely to provide these for the initial release of MDDL.

4. Elements versus Attributes

    The Technical Committee recognizes the classic debate of elements versus attributes in XML structure design as a time consuming and costly process. In order to focus our energy and efforts more on the architecture and detail design of MDDL, a guideline for using elements versus attributes has been established.

    It is recommended that elements be preferred for MDDL document markups. However, the use of attributes is not eliminated entirely. The recommendation is based on the following considerations:

    * General - Elements are good for representing structurally significant information; attributes are more suited for contextual details.

    * Extensibility - Elements are more extensible than attributes in an evolving standard because elements can contain other elements or substructures directly while attributes cannot. If a concept is defined as an attribute initially, and then needs to be expanded to hold fine-grained information, it must be changed to an element to be modeled correctly.

    * Flexibility - Elements can have attributes attached to them as metadata, while attributes cannot. Elements are repeatable within the same container structure, but attributes can only appear once in the attribute list of an element. In addition, if order of occurrence is significant, elements are the only option because attributes do not have order.

    Note that the final choice of architecture for MDDL will be based on a choice between concrete proposals, and not solely on these suggested guidelines. As such, either an element-centric format, an attribute-centric format, or a hybrid of the two could ultimately be chosen for MDDL.

5. Extensibility

    The MDDL specification must allow vendors to add proprietary fields or content not explicitly stated in the original specification as many vendors may find it necessary to distribute fielded data not identified by the MDDL Vocabulary Committee or may wish to distribute proprietary fields not support by other vendors. Additionally, changing market conditions often necessitate modifications or additions that vendors are able to implement on different time scales.

6. Name Space

    Prevalent in the technical web world is the concept of "namespacing" whereby variables are identified not only by their common name but also by the organization or standard assigning the name. In the XML world, namespacing allows an XML document to reference an element from another standard by identifying the namespace of the standard followed by a colon (:) followed by the name of the element to be included (for example, "foo:bar" references the element "bar" from the namespace represented by the prefix "foo").

    MDDL will allow namespaced references to other XML standards. This is particularly essential if a vendor has connected MDDL data it is providing with data from a third party source (like investment reports or corporate statements) and must identify the third party content using conventions from that standard.

    MDDL will also define its own namespace so that other XML standards may reference elements within MDDL. This will be important if a third party content model (perhaps a news story) would like to reference element hierarchies within MDDL (perhaps to provide an inline quote in the news story).

7. Request and Response Mechanisms

    It is agreed that MDDL should provide for both "Request" and "Response" mechanisms and should thus define the formats and contents of requests and responses. However, considering the short time frame to the release of the initial specification (MDDL v1.0) it seems reasonable that the "Request Format" can be deferred until after MDDL v1.0. Thus, MDDL v1.0 can focus on defining the "Data Format" that will be used as the basis for the "Request" and "Response" Formats. The MDDL Steering Committee has been asked to review this position.

    The "Request Format", "Response Format", and the "Data Format" specifications can be developed and used independently although the "Request Format" and "Response Format" will be dependent on the "Data Format". Once the "Data Format" specification has been developed it can be used immediately to deliver content independent of the Request or Response specification. In some cases, Data will be sent on a periodic basis without any Requests from the user (e.g. "cron" triggered jobs or broadcasts). In other cases, Applications and Users can continue to submit their Requests using existing formats without change. In these cases, the Response header could be delivered with the existing format followed by the actual "Data" using the MDDL v1.0 specification with minimal change to the handling software (except to parse the new Data). Hence, Applications will be able to take advantage of the MDDL "Data Format" to receive, parse, and process the data without requiring the MDDL "Request" or "Response" formats to be developed and published. This single accomplishment will be a big win for the Market Data Industry.

    Once the "Data Format" specifications have been published for use in real applications, the MDDL Technical Committee can then shift its focus to enhancing MDDL v1.0 to include the "Request Format" and "Response Format" specifications. Applications, Users, and Vendors can then use these specifications to format their Requests and Responses while continue to use the existing and well understood "Data Format" from MDDL v1.0 for the Data portion of the Response.

    Essentially, MDDL v1.0 will provide a Data representation with the Request and Response mechanisms added as wrappers in a later revision (perhaps MDDL v1.1 or v2.0).

8. Documentation

Documentation will be processed through Technical Committee two "chief editors" for distribution by the Steering Committee via the website. Changes to the technical documentation will approved by the Technical Committee per the editors.

The following documents are considered necessary for inclusion in the final MDDL Documentation Set:

Technical Committee:

  • MDDL Functional Specification
    • Executive Summary
    • Structure
    • Relationship to Other XML Initiatives
    • Position Papers
  • MDDL Technical Specification
    • DTD
    • Schema
    • Examples
    • Diagrams

Vocabulary Committee:

  • MDDL Data Dictionary
  • MDDL Vocabularies

Shared:

  • MDDL User Guide

The following documents are considered essential for the initial release of MDDL:

Technical Committee:

  • MDDL Functional Specification
    • Executive Summary
    • Position Papers
  • MDDL Technical Specification
    • DTD
    • Schema
    • Examples

Vocabulary Committee:

  • MDDL Data Dictionary
  • MDDL Vocabulary

 

 

 



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