FpML Issues Tracker
closed
Crash
Always
Architecture
Admin
mgratacos
Summary
FpML needs a consistent set of Core Data Types. There is a gap today where this part of the standard is left unspecified and it is causing us problems with implementing FpML. There is incompatability between market participants on data types, no agreement on field sizes, and efficiency problems in the implementation.
Here is a proposal for FpML Core Data Types. This is based on the lessons in the large implementations of ISO15000 and ISO20022. This is a custom solution consistent with the architecture of FpML, but harmonious and convergent with the ISO standards.
Please can we review the proposal at the next AWG meeting to consider adoption.
Notes:
matthew
02/15/07 6:57 pm
Added FpML Core Data Types proposal.
matthew
02/15/07 6:58 pm
Added FpML Core Data Types schema.
apparry
03/07/07 10:41 am
JPM supports this ( AJ, AP, MR, HMcA )
We would like to know the implementation plan
mgratacos
08/17/07 7:52 am
Standards Committee minutes on Core Data Types:
Core Data Type Proposal
Marc presented the core data type proposal (see ppt presentation). The proposal, originally discussed in the May SC meeting has been worked out in more detail. Bob Green, Harry McAllister and Pierre Lamy are concerned that the proposal adds another layer of complexity with limited additional value. Some of the motivation for the proposal, originally from Matthew Rawlings, is the compatibility with ISO 20022. The SC indicated that the ISO situation is different as there is no impact on legacy messages. The group generally saw value in having guidelines around most of the proposals in the core data type proposal but enforcing this through schema constraints is a step too far. Brian indicated that firms have problems with consistently applying exactly the type of limitations the core data type proposal seeks to address and that the proposal would simplify electronic message exchange. Bringing the constraints out as guidelines would not be as effective. The Standards Committee advised that the proposal should go back to the AWG and the AWG should look to bring this out as guidelines, not as schema restrictions.
Action: AWG: review and rework the core date type proposal
mgratacos
08/17/07 8:22 am
Some members of the Standards Committee had some issues with the current proposal:
Marc,
I’m afraid my notes are somewhat incomplete also!
I think I made the following points:
IndicatorDataType: the permitted values of xsd:boolean are {true, false, 1,
0} ( see: W3C XML Schema Part 2: Datatypes Second Edition, section 3.2.2).
Therefore (1) the whitespace constraint is ineffective, and (2) the type
declaration fails in the declared aim of supporting “exactly two mutually
exclusive values”. The definition should be derived by restriction from
xsd:boolean, as an enumeration of {true, false}.
Redundant whitespace constraints appear in several other declarations e.g.
CodeDataType (based on xsd:token, which is already whitespace constrained
by definition).
[BasisPoint, Percentage]DataType: by convention throughout FpML, rates,
percentages and basis point values are represented as real numbers (so 1%
is represented as 0.01, 1 bp as 0.0001 etc). The purpose is to avoid
ambiguity of interpretation – the message consumer never has to decide how
to scale a value. The proposed types risk introducing confusion – declaring
an element as a specially named type suggests that its value is denominated
in units of the type, when in fact it is not (what is the intuitive
interpretation of the value 0.5, where the type of the element is
“PercentDataType” …?).
On facets constraining the size/precision of elements: any constraint is
essentially arbitrary, and will either constrain some implementers
unnecessarily, or be so relaxed as to be ineffective in any case. We can’t
anticipate every potential usage, and we shouldn’t apply contstraints in
the schema which would prevent implementers from making legitimate use of
their preferred coding schemes.
I am very much in favour of rationalising the use of primitive datatypes
across FpML (currently inconsistently applied). I believe we risk
compromising the principle of FpML as an open standard by building a
proprietary layer on top of the W3C datatype hierarchy.
Best regards,
Harry
mgratacos
10/18/07 1:51 pm
Just for the purposes of alignment, note that the latest UN/CEFACT core data types are listed here:
http://www.unstandards.org:8080/display/ATG/CDT+Catalogue
These are the types that ISO 20022 is aligning with. This information was updated last week at the UN/CEFACT forum in Stockholm.
Cheers, Tony.
On Thu, 27 Sep 2007 13:38:48 +0100, Marc Gratacos
wrote:
> I’d like to re-launch the work on core data types. Please, see issue
> ticket for some background discussion
> http://www.fpml.org/issues/view.php?id=313
>
>
> My opinion in terms of principles for this:
>
> 1. Enforcement should be done at the schema level, not as
> guideline.
>
> * People pay less attention to guidelines than schema
> definitions.
> * Benefits of schema implementation are not available in a
> guideline document.
>
> 2. Data types should bring value to the grammar. Data types that
> don’t bring any value to existing types or to existing xsd simple
> types should not be incorporated.
>
> * i.e. What’s the value of a new type that is equivalent
> to an existing xsd type?
> * i.e. There is value in having a common data type for all
> schemes. Inconsistency between them is a problem currently.
>
> 3. Convergence with other standards is good and necessary but only
> when types bring value to the grammar and don’t confuse existing users.
>
> * The distinction between basis points and percentage
> would introduce confusion to FpML.
> * What’s the value of having a generic Numeric data type?
>
>
> Opinions on this are very welcome.
>
>
> I’ll send a separate e-mail with my suggested changes to the current
> proposal.
>
>
> Kind Regards,
>
> -Marc
andrew
10/02/08 9:31 am
Some of the proposal changes are now implemented in the schema (e.g. constrained data types like NonNegativeMoney, Scheme vales, etc.) and have been used in recent product model additions.
The architectire specification and modelling guidelines paper recommend the use of facets to constrain the models as much as is practical.
The new types have not yet been retro-fitted into the older product models and are unlikely to be so in the current 4.x series because of concerns over backward compatibility.
In the short term some of these constraints can be implemented as validation rules (as they have for a number of simple conditions in the FX products) with a view to deprecating them at a later time when the models are revised (in 5.0 or later).
andrew
10/02/08 1:49 pm
AWG agreed on 02-10-2008 to close this issue.