1. Experiences and Status
FpML 5.0
Experiences and Status

2. 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.

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

4. 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

5. 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

6. 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

7. 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

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

9. 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 approach

10. 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.

11. 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>

12. 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

13. 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

14. 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?

15. 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