FpML Issues Tracker
Modeling Task Force
Version Identification has been incorporated into FpML (choice between tradeId and versionedTradeId).
Guidelines on how to use versioning are needed.
04/04/07 10:49 am
It must be positive, increasing, and does not need to be monotonic.
06/07/07 1:32 pm
It was agreed at the AWG at 2007-06-07 that this is waiting on Marc Gratacos. Marc will make a proposal.
06/28/07 1:43 pm
At AWG 2007-06-28 Marc commented that he had a proposal which he had asked Brian to comment upon and distribute. Marc will resend this proposal.
AJ suggested this was a BPWG issue.
06/28/07 1:49 pm
Generic principles of versioning components should be added in the Architecture Spec.
08/17/07 8:21 am
Brian will circulate updated version of the document:
1. Extract some principles
2. Changes to existing implementation
08/17/07 12:07 pm
Here are some proposed principles for object identification:
* A token used by an institution to identify a business object (such as a trade) must uniquely identify that object; in other words, it may be assigned to only one object.
* A token used by an institution to identify a business object (such as a trade) must not change during the life of that object.
* Version numbers must be positive and increasing, but do not need to be monotonic (i.e. there may be gaps between the numbers).
* Version numbers may be updated only by the institution that created them and maintains them. In other words, one institution cannot update a version number originally assigned by another institution.
* It must be clear to the recipient of a message what identification token(s) and version number(s) for each business object:
– were assigned by the sender of the message.
– are to be used for retrieving the current known state of the object..
– are to be used for any reporting back to the originator
* If more than one identification token or version may be used for these purposes, an unambiguous rule for resolving identification conflicts must be defined.
* Identification conflict mechanisms that rely on information not contained in the message (for example, ones relying on lists of scheme URIs maintained by the recipient) are undesirable compared to mechanisms that rely only on the message content.
These principles (or some version thereof) should apply to whatever identification solution we agree on,
08/23/07 1:31 pm
AWG: Agreed to incorporate these principles into the Architecture Spec.
Define terms before description: token does not include version.
08/23/07 2:03 pm
To address the previous note, add this definition prior to the first principle:
* An identifying token is a string meeting the xsd:token data type requirements that does not include any embedded version information.
09/17/07 3:02 pm
These principles were added to the trunk. They’ll be published on the Architecture Spec 2.1 Trial Recommendation.
09/22/07 9:02 am
Principles were added to the Architecture document. Implementation is task of the product working groups.
09/22/07 2:35 pm
It doesn’t seem to me that we’ve actually resolved this issue. We did add some principles to the Architecture Spec saying, in effect, that this issue needs to be addressed, but we didn’t say how. We’ve neither updated the guidelines on trade identification, nor made any changes to the identification model.
06/12/20 5:57 am
- Agreement to remodel the scheme and identification types in version 6.0.
- We would like to have a consistent scheme attribute.
- The version number should be an optional attribute, not part of the element name (versionedTradeId).
Leave an update
You must be logged in to post an update.