FpML Versioning

An AWG Discusion Document

Versioning in FpML To Date

• Based on major.minor numbering– Major increments to indicate a breaking change

– Minor increments with each non-breaking change

• 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 difference between all

releases are minor– 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

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?