1. FpML Versioning An AWG Discusion Document

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

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

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

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

6. Options

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

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

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

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

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

12. Other Thoughts Should we have a standard root element attribute that defines schema status? –status=wd or tr or rec

13. Recommendation What?