1 / 16

FpML Versioning

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

jerry
Download Presentation

FpML Versioning

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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?

More Related