Experiences and Status FpML 5.0 Experiences and Status

Current Model Summary FpML 1.0 thru 4.2 are all single namespace Keeps instance documents simple Products largely modelled from post trade point of view Strict type model ensures ‘whole’ product must be specified A range of ‘generic’ names given ‘specific’ post trade interpretations.

Approaches to Modelling ‘State’ Quotable products Limited number of namespaces Too many namespaces Schema generation

Quotable Products Introduced in FpML 4.0 to model RFQ process Only implemented for FX product Creates a new family of products Prefixed to avoid collision with existing products No direct relationship between pre-trade and post-trade types Disjoint inheritance structures Consistency by review only

Limited Number of Namespaces Small number of ‘view’ schemas Constructed from chameleon schemas containing components Pros & Cons Complex internal schema include structure Difficult to factor out view specific/generic types Difficult to create standalone valid subschema files High redundancy of types between views

Too Many Namespaces What if every FpML type had its own namespace? Most XML tools can’t cope! Pros & Cons All the complexity can be hidden in the schema But editing them is really hard

What have we learnt? XML Schema is not very good at representing different points of view Some of the schema features to create views have issues with tools Multiple namespaces in a schema or document should be avoided But small extension schemas work well Code generation is a much better option

Code Generation Software Engineering approach:- Ontological approach:- Model everything UML Ontological approach:- Model everything in OWL/RDF Pragmatic approach:- Add annotations to XML Schema

Modelling in UML UML tools are commonplace But targeted at software rather than message design XML Schema is almost but not quite object oriented like UML XML Schema is grammar oriented A,B?,(C?|(D, E)),F becomes flattened in UML & field dependencies are lost. Order is difficult to express in UML Especially for associations Current ISO 20022 approach

Modelling in OWL/RDF W3C recommendation since 2004 Part of the semantic web project Tools currently immature and only partial process coverage Properties are used to define and relate instances Classes identify instances having common properties (e.g. swaps vs. FX options). Classes can have relationships with other classes Incorporates both structural definition and business rules within a single set of definitions.

Extended Schema Use annotations to provide alternative values for XML ‘facets’ in different views Type, Min Cardinality, Max Cardinality, etc. <xsd:element name="relativeEffectiveDate" type="AdjustedRelativeDateOffset"> <xsd:annotation> <xsd:appinfo reporting:minOccurs="0" confirmation:skip="true"/> <xsd:documentation xml:lang="en">Defines the effective date relative to the trade date, typically in months.</xsd:documentation> </xsd:annotation> </xsd:element>

Extended Schema Generate different views by processing .xsl An XSLT script takes the schema with annotations (extended) and generates the different view schemas (standard schema files) Each is a complete and disjoint schema – no interlinking Reporting Schema Extended Schema .xsl Confirm Schema

Extended Schema Pros Instance documents remain simple Current design tools continue to work Each subschema file is valid Only types affected by views need annotations No redundancy on the source schema file ACCORD standard uses a similar technique

Extended Schema Pros & Cons Annotations will not be drawn in design tool Increases the size of distributed FpML Schema Some work needs to be done on documentation Should we publish the source schema? Or only the view schemas?

Recommendation Generation from XSD schema is the most promising approach to date Some small XML problems to resolve Longer term OWL/RDF is the W3C’s strategic solution for information description Tools are currently immature But we should keep an eye on it