FpML Issues Tracker
assigned
Minor
Always
Modeling Task Force
FpML 6 (Build 1)
none
Admin
BrianLynn
Summary
Version Identification has been incorporated into FpML (choice between tradeId and versionedTradeId).
Guidelines on how to use versioning are needed.
Notes:
matthew
04/04/07 10:49 am
It must be positive, increasing, and does not need to be monotonic.
matthew
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.
matthew
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.
mgratacos
06/28/07 1:49 pm
Generic principles of versioning components should be added in the Architecture Spec.
mgratacos
08/17/07 8:21 am
Brian will circulate updated version of the document:
1. Extract some principles
2. Changes to existing implementation
BrianLynn
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,
mgratacos
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.
BrianLynn
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.
mgratacos
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.
mgratacos
09/22/07 9:02 am
Principles were added to the Architecture document. Implementation is task of the product working groups.
mgratacos
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.
Brian
mgratacos
06/12/20 5:57 am
AWG 2020-06-04