ࡱ > d f c q j bjbjVV 4 < < b D _ _ _ _ _ s s s 8 4 | s 3 [ 3 ( [ [ [ 6 6" # t "3 $3 $3 $3 $3 $3 $3 $ E5 7 H3 _ # 6 6 # # H3 _ _ [ [ ]3 % % % # _ [ _ [ "3 % # "3 % % 0 2 [ ROt s $ 2 4 3 s3 0 3 2 4 8 % . 8 h 2 8 _ 2 # # % # # # # # H3 H3 % # # # 3 # # # # 8 # # # # # # # # # % :
Technical Note: Migration to XML Schema
Abstract:
In this paper, the Architecture Working Group explains the decision that XML Schemas should supersede DTDs to define future FpML specifications. We describe the main advantages of adopting XML Schemas and the timeline in which the transition should take place. Furthermore, we address some of the issues that the transition phase will raise and we identify others that need further work and discussion.
This version:
HYPERLINK "http://www.fpml.org/documents/working-papers/technical_notes/XMLSchemaRec2002-04-03.doc"http://www.fpml.org/spec/XMLSchemaRec2002-04-03
Latest version:
HYPERLINK "http://www.fpml.org/spec/fpml-3-0/tech-note-xmlschemarec/"http://www.fpml.org/spec/XMLSchemaRec
Copyright 2001-2002. All rights reserved.
Financial Products Markup Language is subject to the FpML public license.
A copy of this license is available at HYPERLINK "http://www.fpml.org/license/license.html" http://www.fpml.org/license/license.html .
Status of this Document:
The Architecture Working Group has produced this document with feedback from the Standards Committee and relevant product working groups as part of the FpML Version 2.0 Activity to identify the issues and time scales related to migrating from DTD based specifications and documents to XML Schema.
It is available for public review during the Trial Recommendation stage ending March, 2002. The FpML Consortium invites implementation feedback during this period. Comments on this document should be sent via e-mail to HYPERLINK "fpml-issues@yahoogroups.com"fpml-issues@yahoogroups.com. Please report each issue in a separate e-mail. An HYPERLINK "http://www.yahoogroups.com/messages/fpml-issues"archive of the comments is available together with an HYPERLINK "http://www.yahoogroups.com/files/fpml-issues/issues-list.html"issues list.
While implementation experience reports are welcomed, the FpML Consortium will not allow early implementation to constrain its ability to make changes to this specification prior to final release.
Authors
Kulbir Arora Goldman Sachs & Co.Tom Carroll UBS WarburgIgor Dayen Object Centric SolutionsDaniel Dui University College LondonAndrew Jacobs IBMRajeev Kotyan IONANed Micelli ReutersAndrew Parry Deutsche BankAshutosh Tripathi NetSysTechnologiesAcknowledgments
Andrew Diamond CalleoWolfgang Emmerich University College London
Table of Contents
TOC \o "1-2" 1 Introduction PAGEREF _Toc533577861 \h 5
1.1 Purpose PAGEREF _Toc533577862 \h 5
1.2 Why migrate to XML Schemas, anyway? PAGEREF _Toc533577863 \h 5
1.3 Scope/Key Issues PAGEREF _Toc533577864 \h 6
1.4 Anti-scope PAGEREF _Toc533577865 \h 6
1.5 Approach PAGEREF _Toc533577866 \h 7
1.6 References PAGEREF _Toc533577867 \h 7
2 Issues PAGEREF _Toc533577868 \h 8
2.1 Validity of FpML 1.0 recommendations in a XML Schema environment PAGEREF _Toc533577869 \h 8
2.2 Migration and Timing Issues PAGEREF _Toc533577870 \h 8
2.3 Architectural Guidance PAGEREF _Toc533577871 \h 12
3 Follow up plans PAGEREF _Toc533577872 \h 15
Introduction
Purpose
This discussion paper sets forth the FpML Architecture Working Group's initial position on the uptake of XML Schemas as a tool for creating future FpML specifications. It establishes the scope of issues the WG considers important in the adoption of XML Schemas, provides answers for some of these issues, and proposes an approach for addressing the remaining issues. Its goal is to provide a set of recommendations for activities in the coming year for the Architecture WG, as well as architectural guidelines for the other WGs in FpML.
The Architecture WG has considered the topic of XML Schema adoption carefully, and as a result has identified a number of architectural issues that will be important to address prior to wholesale adoption, as well as issues pertaining to the effective usage of features in XML Schemas in the FpML domain. The WG has subsequently divided these issues into those that can be sufficiently addressed in this paper and others that will require further work in determining the best course of action for FpML.
We take the general stance that the transition from DTD to XML Schemas should happen as as soon as possible but in a manner which does not conflict with the scheduled deliverables of the current product working groups. The AWG will recommend full use of all the features of XML Schemas except those that would make impossible or impractical the coexistence of Schemas and DTD definitions of the same FpML specifications and except those features that are not well supported by current software tools. After the transition period we will allow only Schema definitions and we will drop support for DTD.
Why migrate to XML Schemas, anyway?
For the technologist, the answer to "should FpML be migrated to XML Schemas?" is frequently a simple "of course", as newer technology is often automatically viewed as superior to current technology. However, XML Schemas offer a variety of features that make it more than just "newer", and in particular support capabilities that mesh well with a variety of FpML's goals:
XML Schemas are the future for XML. DTDs are a dead-end technology, in terms of both vendor support and ongoing work in the W3C. While DTDs support will never completely vanish, the majority of technological advances and all new W3C specifications will be done in alignment with XML Schemas, not DTDs.
XML Schemas have better support for defining reusable structures in an object oriented fashion, which will make extending the scope of FpML's specifications simpler to do and simpler to integrate into business processes. These features had to be coerced into the DTD-based specifications, as there is no direct support for such notions in DTDs.
XML Schemas provide direct support for extensions, which is an important feature when organizations want to make further use of FpML within their own internal systems. Again, DTDs lack such support.
XML Schemas have facilities that make adding attachments and other addenda to a instance document more straightforward than possible with DTDs.
XML Schemas are fundamentally better designed to allow for independent, de-coupled development groups to work on different parts of a specification, with minimal cross-group interaction required, and without necessitating a new revision of the entire specification if only one of the parts changes. DTD support in this area is minimal, and requires a new overall release if only one "part" changes.
XML Schemas themselves are expressed in XML, unlike DTDs which are written in their own language. This simplifies training for developers who will work with the standards generated.
Going forward, XML Schemas will enjoy better tools support from vendors and the Open Source community than will DTDs.
There are also deeper technical advantages, such as namespace support and better support for references, but from a business perspective, the above reasons make a compelling case to migrate FpML to XML Schemas for both business and technical people.
Scope/Key Issues
The issues identified by the Architecture WG can be partitioned into three broad categories:
Validity of FpML 1.0 architectural recommendations in a XML Schema environment. The Architecture WG has reviewed a number of topics from the 1.0 Architecture recommendation which intersect with parts of the XML Schema specification to determine if these initial recommendations still valid, or must be changed in some fashion for better adoption of XML Schemas.
Migration and Timing. There are a number of different issues pertaining to the impact XML Schema adoption will have on existing code and instance documents. Additionally, the timing of this migration will need to be considered and planned carefully, especially in the current FpML organizational environment where different product groups are progressing independently of one another.
Architectural Guidance. XML Schemas provide a significant number of new features and expressive power, but not all of these are in the best interests of FpML to utilize, or else their use should be channeled into specific usage areas. These features need to be identified and best/consistent practices established.
Anti-scope
The following topics are not in the scope of this paper:
Alternative schema and validation mechanisms such as RELAX
The implementation of XML processing tools (e.g. parsers, validators, etc.) should not concern FpML users.
Changes or extensions to the expressive capacity and range of FpML
Approach
The approach taken to produce this paper is straightforward:
Enumerate issues related to XML Schema adoption
Describe each issue in sufficient detail so that subsequent discussion can take place.
Either address the issue here, or identify the issue as being one requiring further work
Present a proposed schedule for addressing these remaining issues
References
This paper refers to material found in the following documents:
FpML 1.0 specification HYPERLINK http://www.fpml.org/spec/2001/rec-fpml-1-0-2001-05-14/index.html http://www.fpml.org/spec/2001/rec-fpml-1-0-2001-05-14/index.html
FpML Architecture 1.0 HYPERLINK http://www.fpml.org/spec/2001/rec-fpml-1-0-2001-03-16/index.html http://www.fpml.org/spec/2001/rec-fpml-1-0-2001-03-16/index.html
FpML Scheme Technical Note
XML Schema specification HYPERLINK http://www.w3.org/XML/Schema#dev http://www.w3.org/XML/Schema#dev
XML Namespaces specification HYPERLINK http://www.w3.org/TR/1999/REC-xml-names-19990114 http://www.w3.org/TR/1999/REC-xml-names-19990114
Links to articles we used in forming our recommendations HYPERLINK http://www.xfront.com/BestPracticesHomepage.html http://www.xfront.com/BestPracticesHomepage.html
Issues
Validity of FpML 1.0 recommendations in a XML Schema environment
Is the mapping to XML Schema as defined in the 1.0 Architecture still valid?
Yes. The approach in the 1.0 architecture specification is in line with the final W3C XML Schema recommendations and results in good XML Schema definitions.
Is the current referencing scheme compatible with XML Schemas?
Yes. The inter-document referencing scheme developed for FpML 1.0 uses XLink syntax (but is not XLink technology dependent) for expressing references but is not checked by the parser at present.
Are there any features of XML Schema that could be used to improve references?
Yes. The XML Schema standard defines a validated reference data type that could be used to hold intra-document references, however its values are slightly different (e.g. DTD #link becomes link). This minor change would require more rewriting between DTD document instances and those for XML Schemas. The course of action to take here is still a matter for further consideration.
The scheme used for inter-document links will not be changed.
Migration and Timing Issues
How will initial DTD to XML Schema translations be done?
Current thinking is that an example translation of the existing 1.0 DTD be done by the Architecture WG members. This translation will be a hand-generated one rather than an automated translation. There are a number of reasons for this approach:
the Architecture WG has yet to document all issues it considers best practice in the use of XML Schemas, and therefore feels that it is in the best position to translate existing DTDs in line with the groups thinking,
the 1.0 DTD contains some inconsistencies which cause automated translators to produce much larger XML Schemas than can be done by hand,
automated tools cannot identify and effectively translate higher-level constructs like the entity base types in the 1.0 DTD, again resulting in a larger XML Schema than would otherwise be produced by hand, and
automated tools cannot effectively translate FpML data types into corresponding XML Schema primitive datatypes.
The Architecture WG also feels that by providing the initial translation of an existing DTD, they can establish the baseline set of best practices that will ultimately be the made an official recommendation from the WG.
What is the anticipated timetable for moving to XML Schemas?
The current product working groups (e.g. Interest Rate Derivatives, FX and Equity derivatives) are already too far through their development process to burden them with the additional task of generating XML Schemas and updating their documentation. For these groups, the additional effort required to produce a XML Schema version of their respective DTD specifications should be scheduled post delivery of their last call working drafts or trial recommendations.
Adopting this approach will lead to a transitional period where the main format for exchanging information between organisations will be DTD-based instance documents, although XML Schema-based documents may be acceptable to some institutions (possibly after translation).
The Architecture WG will engage with the Interest Rate Derivative Product WG to assist in the production of a translation of the DTD for the 2.0 trial recommendation as an accompanying technical note. This initial translation will use a constrained set of XML Schema features to minimise differences between DTD and XML Schema document instances.
The availability of this XML Schema will allow interested parties to begin using XML Schema technology in parallel with DTDs. The following diagram shows the expected time line in the transition to XML Schema.
EMBED Word.Picture.8
Any new product or business process working groups starting in the near future to produce specifications for FpML post release 3.1 should target XML Schema as their main deliverable, with optional support for DTDs. This will encourage uptake of XML Schema whilst allowing continued use of DTD based documents for established products. At some point we expect to see support of DTDs as unnecessary.
When will XML Schema become the standard representation for FpML?
The AWG feels that from FpML 4.0 XML Schema should replace DTD as the main deliverable although updated DTDs may additionally be provided if there is sufficient interest by consortium members.
The AWG expects that FpML release 4.0 will occur sometime in 2003.
How much impact will changing to XML Schemas have on existing code?
The intention is for FpML documents referencing a XML Schema to be only minimally different from existing documents referencing DTDs. This should make it easier for developers to migrate existing code to XML Schema technology.
The key change to the FpML document will the addition of XML Schema references in the header of FpML instance documents, as illustrated in the following XML fragments.
DTD-based instance document header:
Lots more here
XML Schema-based instance document header:
Lots more here
It should be noted that XML Schema has no formal prohibition on using the directive, so processing software should ignore resolving external references from instances of .
XML Schema based FpML document instances will not declare or use namespaces (other than those necessary to use XML Schemas themselves).
What is the impact on SAX/DOM users?
Code based on the standard APIs for processing XML documents (e.g. SAX and DOM) will be largely unaffected given that the structure of the document (e.g. order of elements) and the element names will be unchanged. Organisations that have implemented bespoke means of XML parsing and/or validation will need to review their own code bases to determine the impact.
How can we be sure that the XML Schema and DTD exactly match?
The Architecture WG is not considering recommending the creation of an automated tool that will formally prove that the FpML DTDs and XML Schemas recognise and validate the same XML grammar. However, if such a tool becomes available either commercially or through academic channels, the WG will consider recommending its use.
Instead, the WG believes that FpML should develop a library of test documents for regression testing that will allow DTD and XML Schema users to check the conformance of the implementation they are using. This document set will act as the reference against which all implementations will be judged, as well as providing the means to test backward compatibility (or planned incompatibility) of older documents with newer versions of the FpML spec. How this document set is created and what it should contain is a matter for further consideration.
Could a tool be used to perform the DTD to XML Schema translation?
Many XML design tools will read a DTD and convert it into an equivalent XML Schema definition, however these tools are not able to recognise features such as the inheritance structures implied by the entities in the FpML 1.0 DTD. Converting the DTD by hand propagates these concepts forward, and produces a more compact and logically structured XML Schema than any of the tools.
There is a danger with hand translations in that errors may be introduced which change the grammar recognised by the XML Schema, making the XML Schema subtly incompatible with the grammar specified by the "equivalent" DTD. Besides careful coding and multiple checks of these translations, it will be important to have a suite of reference documents (as mentioned above) to ensure that the XML Schema properly recognises the grammar that is considered to be the standard for FpML.
Should we have a period of no namespace use to ease transition to XML Schemas?
Yes. Use of namespaces in FpML instance documents would create larger and more difficult to read documents as well as compounding implementation difficulties during the DTD/XML Schema transition period. They will not be used during the transition period.
How much impact should XML Schemas have on current DTD referencing documents?
The recommendations outlined in this paper maintains maximum document compatibility between DTD instances and XML Schema instances.
Should it be possible to translate instances automatically?
Yes. The changes are relatively simple and could be performed on a document instance by a simple program or text processing utility (e.g. awk, perl, etc.).
Will 1.0 inconsistencies be addressed in the migration to XML Schemas?
Yes, but not initially. The Architecture WG feels that there will be sufficient change in the switch to XML Schemas themselves that addressing 1.0 inconsistencies at the same time would entail too great an implementation risk to FpML users & implementers. However, the WG also feels that since this will be a time of some upheaval, this is probably one of the best opportunities well have to correct the inconsistencies in the 1.0 spec so that moving forward well have a more consistent specification from which to work. The exact scope of these changes, and their timing, is a topic for further consideration.
Architectural Guidance
How much of the XML Schema standard is supported by commonly available tools?
A good deal. Experimentation has shown that the vast majority of XML Schema features are well supported by the existing implementations. A small number of problems have been identified but these can be easily avoided in the short term. The parts of XML Schemas that the Architecture 1.0 recommendation addresses are well supported. However, due to some of the newer goals of FpML in terms of product group organisation, there may be some problems in using multiple XML Schemas with the current tools. The issues impacting this latter case will be addressed by the AWG.
Should local element definitions be allowed initially?
No. Initially, FpML elements should be global (as specified in the 1.0 Architecture recommendation) to ensure complete compatibility with DTDs. When DTDs are no longer supported in FpML, global data holding elements may be converted to use local scope rules. This should not have any impact on the interpretation of FpML documents created with prior XML Schema definitions
Would it be easier to support extensions and attachments in just XML Schema only?
Yes. These features will be very difficult or impossible to achieve with DTDs. It may only be possible to support them in XML Schemas (through the use of features such as type inheritance, dangling types, etc.).
Can XML Schemas model O-O style inheritance?
Yes. XML Schemas provide several techniques for modelling inheritance. The article at HYPERLINK http://www.xfront.com/VariableContentContainers.html http://www.xfront.com/VariableContentContainers.html articulates the available techniques, and their respective pros and cons clearly and concisely.
Are substitution groups the correct technique to use to model inheritance?
Possibly. Substitution groups as used in the FpML 1.0 Architecture allow the definition of placeholders in an XML Schema that may subsequently be replaced with other conforming elements. Importantly, the replacing elements can be defined without modifying the original XML Schema. This will allow FpML working groups or users to create additional data structures whilst remaining compatible with the official FpML release. However, substitution groups have some restrictions on how they are used, which may have implications on FpML specifications.
Other techniques for representing inheritance, or implementing variable content containers, have their own tradeoffs. The Architecture WG will need to study these different approaches, and choose from among them the ones that best suit the manner in which ongoing FpML product development will proceed.
Should we consider the use of inheritance by restriction?
Yes. The FpML 1.0 architecture specification only considered the extension style of inheritance used by most object-oriented design techniques and programming languages. It does not disallow the use of restriction, however no specific reason for considering that method was identified at the time the specification was written. The Architecture WG sees no reason to change that position.
Will FpML define its own complete set of types or only add where needed?
Where possible, FpML should use standard XML Schema datatypes (already referenced by the DTD through the type attribute). Additional types may be defined for financial-specific items where no equivalent standard exists.
Should enumerations be used instead of schemes for domains where no future changes can be envisaged?
Unclear at this time. The initial translation to XML Schemas will have to maintain compatibility with the current domain representation as described in the FpML Scheme Technical Note, however XML Schemas offer more support for enumerations and will be considered by the AWG for later adoption. This will be investigated further by the Architecture WG.
Should bounds checking be added to elements where clear limits exist?
Yes. Where additional validation checks can be incorporated into the XML Schema without violating compatibility with the original DTD they may be added (e.g. lower and upper bounds, etc.). The task of adding such checks will require business domain knowledge and the involvement of the product working groups.
Can the version features be extended to allow a Schema/DTD to match previous compatible versions?
This is a topic for further consideration by the Architecture WG.
Can version compatibility (e.g. is 2.0 an exact subset of 1.0, or vice versa) be assured?
This is a topic for further consideration by the Architecture WG.
Do we need to address version interoperability in this recommendation or flag it as an issue?
This is a topic for further consideration by the Architecture WG.
The DTD is being split into modules to allow WGs to extend in parallel, but referencing documents wont see this. Can the same be true of XML Schema?
The Schema specification provides a facility to import or include definitions from other schema files, however experimentation has identified problems with the use of include which have not yet been resolved. This is a topic for further consideration by the Architecture WG.
Follow up plans
Following on from this recommendation the Architecture Working Group recognises that a greater understanding of the some parts of Schema usage are required. As a result the following issues will be considered as part of the AWGs main deliverable in 2002 (in approximate order of priority):
Definition of Schema modularity and inheritance
Produce a schema version of the 2.0 DTD
Elimination of inconsistencies in the FpML grammar
Regression testing of FpML DTDs and Schema
Examine the use of XML Schema with respect to references
Clarification of document versioning issues
Modelling of extensions and attachments
Modelling of simple and unchanging domain values
PAGE 25
FpML 2.0 Technical Note PAGE 2
/ 2 D
E
F
u
v
x
Ὸ}ke`V j hWV 5U h)q<