FpML Issues Tracker

Summary

In section 7 of the April 17 WD of FpML 3.0, there was a proposed change to the use of scheme defaults:

Here is the text of the proposal:

Quote: "The FpML Working Groups are considering removing the scheme default attributes from the FpML root element and changing the scheme attributes from being #IMPLIED to #REQUIRED. Comments and feedback on this idea are encouraged.

This change is proposed because where scheme default attributes are used the meaning of a given node is dependent on the document it is in. This means that if part of an FpML document it copied from one document to another then it's meaning may change if the scheme default attribute is different " End Quote.

JPMorgan Feedback:

JPMorgan strongly opposes the proposed change. JPMorgan feels that the proposed change has the following adverse consequences: * Greatly increases the size and bulk of messages, particularly for portfolios of trades * Reduces the readibility of FpML documents. * Increases the difficulty of verifying which schemes are used for each trade, since there is no way to factor out common definitions. * Makes it more difficult to build efficient processing logic, because schemes will always need to be verified for each element independently, rather than defaulted and overridden only as necessary.

JPMorgan does not feel that the stated benefits of the change warrant the drawbacks.

JPMorgan proposes the following instead:

Add the following directives, or equivalent, to the standard:

1) In an FpML-compliant document, there must be an scheme definition available for each element requiring a scheme. This scheme definition can be specified, for example, either at the document root level ( tag) or for each individual element, or in other ways as may be defined in FpML in the future. (For example, by inheritance from a parent document or by inclusion of/reference to another document). Implementers are responsible for validating (at document validation time) that there is a scheme definition available for each element requiring a scheme, and reporting an error if not. [Comment: as more ways to define schemes are created, a disambiguation hierarchy/scoping rules should be defined, e.g. element-level scheme definition supercede document-level definitions which in turn supercede scheme definitions inherited from a parent document].

2) When comparing or copying elements that use scheme definitions between FpML documents, implementers must ensure that the scheme definition are compatible. For example, if a source document defines scheme defaults at the root element that are different from those defined in the destination document's root element, the implementer must either determine that the schemes are equivalent (Equivalency definition TBD), or set the scheme attribute in all copied nodes to the scheme definition URI contained in the source document."

[End of proposed additions to the standard].

In general this proposal has more to do with the semantics of how an FpML document is to be processed than in how it is structured. Document processing is an area the FpML does not currently specify in any detail. For example, there is little coverage at this point of how to validate an FpML document, how to compare two documents, etc. JPMorgan believes that changing the document structure to "simplify" processing without having discussed document processing in any detail is premature. Instead, this type of change is perhaps better addressed as part of a WG on document processing (e..g validation, matching). For example, the definition of equivalency between two scheme definitions is unclear. Do the URIs have to be identical, or do only the contents need to be identical, or do only the values used in the source need to be defined in the destination? This might be a choice that an implementer can make, perhaps associated with different warning levels.

This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase & Co., its subsidiaries and affiliates.