1. FpML Versioning An AWG Discusion Document

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

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

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

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

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

7. Options

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

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

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

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

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

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

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

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

16. Recommendation What?