FpML Issues Tracker
closed
Minor
Always
Schema
Admin
mgratacos
Summary
This is my feedback on implementing the TR:
Each .xsd file used to be valid independently. They imported everything they needed to be valid by themselves. Within the 4.0 TR this holds for all files except fpml-msg-4-0.xsd. This file has dependencies on types such as 'Document' and 'Trade' that are defined in fpml-main-4-0.xsd. The circular link occurs because fpml-main-4-0.xsd includes fpml-msg-4-0.xsd.
fpml-main-4-0.xsd as the main file remains valid because include mechanisms are used. So I accept we can get by with the current situation. My preference for independently valid .xsd files is primarily for ease of use with 3rd party tools, secondarily to simplify extensions and overriding, and lastly for architectural simplicity.
I have looked at the architecture specification for guidance. It says nothing explicit that I could find, but to me it breaks the spirit of a modular structure: http://www.fpml.org/spec/2003/wd-fpml-arch-2-0-2003-12-10/wd-fpml- arch-2-0-2003-12-10.htm#S5-2.
Is it possible to resolve this? I hoped so as it wouldn't change the structure of the resultant FpML.
Notes:
mgratacos
04/13/05 7:09 pm
This problem was introduced in the LCWD, when messaging definitions were split
into a separate schema file. We have been aware of it since then, but have
not yet resolved it.
The problem is that the fpml-msg subschema references definitions in the main
schema file, but cannot reference the main schema without creating a circular
definition. I.e. the definitions in the subschema are incomplete by
themselves; they work only if the whole schema is included. We considered
this to be a relatively minor if annoying problem.
We are looking into correcting this problem by moving the bulk of the root
definitions in fpml-main into a new subschema file (e.g. fpml-doc-4-0.xsd or
fpml-trade-4-0.xsd), or perhaps into fpml-shared. A direct consequence of
this change would be a substantial change to the organization of the subschema
documentation (this is the main reason we have not yet introduced the
change). If we introduce this change, the fpml-main.xsd will contain little
more than a series of subschema includes and a definition of the
element.
We believe that this change would have relatively little impact on existing
implementations, would make it easier for implementers to create subsetted
versions of the FpML schema, and may make the dependencies of the definitions
a little clearer.
We may introduce this change in an updated version of the 4.0 trial
recommendation, or in the recommendation itself.
– Brian Lynn