FpML Versioning

An AWG Discusion Document

Namespace URIs & Versions

• An XML parser locates the schema for a document based on its namespace URI

• To be backwards or forwards compatible the namespace used to reference the schema MUST be the same across several versions– Otherwise you MUST edit the instance to change the namespace

before reprocessing

• You can not use resolution to map several namespaces to the same schema– The parser detects that the namespace used within the schema is

different from the one being referenced– Neither can you resolve to a chameleon schema with no target

namespace

Versioning in FpML To Date

• Based on major.minor numbering– Major increments to indicate a breaking change– Minor increments with each non-breaking change

• Instance documents can only be processed against the specific schema they reference– Must be edited to use another

• Numbering rules have not be rigorously implemented– 4.1 EQD model incompatible with 4.0– 4.3 CD model ‘technically’ incompatible with 4.2

Technical vs. Marketing Numbering

• Standards committee prefers to minimise major number changes– Makes it ‘seem’ that differences between all

releases are minor – historically not true– Must read the release notes to discover the

details of the changes

• Goes against FpML rules of operation

Why Change?

• To implement document backwards compatibility– Compatible schemas must share a common namespace

• Most FpML releases are ‘structurally’ backwards compatible BUT documents must be altered before processing– Change would eliminate need for document alterations

– Can reduce the maintain required to update implementations

Build Numbers

• Can be considered as an additional part of the version number– e.g. Major.Minor.Build

• Useful to implementers using working drafts

• No changes to build numbers are considered

Options

Option 1: Continue Ad-hoc Numbering

• Continue with current system for 5 and later• Pros:

– More control over version numbering

• Cons:– Not possible to implement backwards

compatibility– Versions give no indication of technical

difference since last release

Option 2: Rigorous Two Part Numbering

• Implement version rigorously to FpML operating rules– Current FpML 4.3 should be 6.1!

• Pros:– Version numbers reflect technical difference and ease of

implementation– Allows backwards compatibility through namespace URI

containing only major number

• Cons:– Major version numbers would increment more frequently

Option 3: Two Versions

• Each schema given two identifiers– A marketing name used in publications

• e.g. FpML 5-A

– A technical major.minor number in the schema

• Pros:– Marketing identifier changes less frequently than technical version

• Cons:– Not easy to determine compatibility from marketing name– Not easy to map between marketing and technical numbering– Namespace based on marketing name would not support

backwards compatibility

Option 4: Three Part Version Number

• Version number becomes– Architecture.Major.Minor (e.g 5.0.0, 5.0.1, 5.1.0)

• Schema namespace URI predictably derived from version number– Architecture.Major (e.g. 5.0, 5.1)

• Pros:– Leading digit remains consistent across many releases

– Supports document backwards compatibility

• Cons:– Architecture number out of synchronisation with documentation

• Come up with a better name?

– Changes version attribute

– Version is not a number - may affect some implementations

Option 5: Three Separate Values

• The version ‘number’ in Option 4 is not a syntactically valid number– Has two decimal points

• Could use three different attributes

• Derive namespace from Architecture and Major numbers

Option 6: Backwards Compatibility Attribute

• Define additional attributes to define minimum compatible version number

• [AJ] How does this help define a series of compatible namespace URLs?

Observations

• Implementers need to see how similar or different releases are– Current scheme ‘disguises’ the amount of

change

• Backwards compatibility can only be done if version numbers are technically defined– Breaking changes MUST change the URI

Other Thoughts

• Should we have a standard root element attribute that defines schema status?– status=“wd” or “tr” or “rec”

Recommendation

• What?