1. FpML Core Data Types Proposal to the AWG Core Data Types Matthew Rawlings, 14 th February 2007

2. The problem today FpML fails to distinguish reliably and consistently between data types and class types The cause is that XML Schema does not enforce a distinction between data types and class types The solution is for the FpML Architecture to provide the distinction by convention between data types and classes to fill the hole in XML Schema FpML does not have a standard set of data types The product and process WGs in FpML today have the full palette of any legal XML Schema type This is a cause of inconsistency across WGs e.g. xsd:string versus xsd:normalizedString This is a cause of missing information such as maximum field lengths The solution is an FpML architecture list of data types for the WGs to use Examples of problems maxLen is undefined for many classes e.g. EntityName. We cannot efficiently support arbitrarily large fields in many technologies, e.g. RDBMS. There are 31 different types of name property used in FpML with different or undefined definitions of name and length. There are 85 places where normalizedString is extended but no maximum length is defined. There are 89 occurrences of a scheme where the identifier value has no maximum length. Too little use is made of tighter data types. For example intermediarySequenceNumber should be a xsd:positiveinteger and not an xsd:integer. Restrictions on negative values are frequently missing. The definition of what is legal in FpML is too loose. Real world enterprise applications are unable to digest valid FpML documents. Field lengths and sizes are undefined There is a lack of consistency making software development more difficult

3. The proposal A standard set of core data types for FpML Defined as xsd:simpleType with a few xsd:complexTypes. The business and process WGs use the standard set of data types instead of directly using xsd datatypes All facets completed correctly including minimum length, maximum lengths, patterns, datatypes, whitespace, abstractness A precise definition for each core data type Applied consistently A complete solution in the core-data-types branch Schema file https://dedicated.fpml.org:8443/viewcvs/branches/core-data- types/src/schema/fpml-core-data-types.xsd?rev=1355&view=log https://dedicated.fpml.org:8443/viewcvs/branches/core-data- types/src/schema/fpml-core-data-types.xsd?rev=1355&view=log The FpML Core Data Types are easily identified because they contain the postfix DataType to their name. A more FpML friendly version of existing standards ISO 15000-5 CCTS Core Data Types ISO 20022 Version 1 Repository ISO 20022 Version 2 Metamodel

4. Data type versus Class type A datatype describes values that lack identity (independent existence and the possibility of side effects). This means dataTypes cannot be instantiated, they are a pure value. A class is a named description of both the data and behaviour of a set of objects. Instances of classes can be created. For example in Java, int is a data type and Integer a class type. For example in UML both datatype and class are distinct subtypes of classifier.

5. The proposed list of data types Simple Types BasisPointDataType CodeDataType DateDataType DateTimeDataType DurationDataType IndicatorDataType NameDataType NumericDataType PerCentDataType RatioDataType TextDataType TimeDataType ValueDataType Complex Types BinaryDataType IdentifierDataType IdentifiersDataType MoneyDataType QuantityDataType

6. Adoption Simple types do not affect document backwards compatability Complex types are consistent with the architecture and therefore not backwards compatible with inconsistencies E.g. // basketId /@scheme instead of basketId /@ basketIdscheme E.g. //calculationAmount/currencyId instead of //calculationAmount/currency Simple types can be adopted in 4-3, complex types for new structures only until 5-0.

7. Benefits of consistent Core Data Types Greater interoperability of FpML implementations Less ambiguity and custom profiles in interpreting FpML Clearer definition of FpML Consistency of FpML Increased alignment and influence with ISO 20022 and ISO 15000

8. Final steps Reach agreement at the AWG Consider the experience of: Tony Coates (ISO15000 & ISO20022) Marc Gratacos (ISO20022) Andrew Jacobs (ISO20022) Andrew Parry (ISO20022) Matthew Rawlings (ISO20022) Decide when to implement