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: The
following documents are considered essential for the initial release of MDDL:
Technical
Committee: - MDDL
Functional Specification
- Executive
Summary
- Position
Papers
- MDDL
Technical Specification
Vocabulary
Committee: - MDDL
Data Dictionary
- MDDL
Vocabulary
|