I received useful critical feedback from my peers within JP Morgan Chase
which I will pass on with my own comments:
* The problem is there are multiple and incompatible ways of
treating a sequence of messages within FpML as this aspect is not formally
specified in the standard.
1. btw - I believe after discussion with Marc the text notes and
examples are non-normative.
* A concrete example is the mis-keyed trade: A trader types a trade
into a booking system incorrectly. When the trade is corrected there are
currently many way this can be represented, and many ways it can be
understood.
1. I have attached a spreadsheet below which shows 6 different ways I
have seen of treating corrections.
2. The examples are anonymized but I can say they include industry
utilities and the largest players in the market.
* Systems that are FpML compatible at the message level are not
compatible when glued together because they have different semantics for
the same message sequence. The standard is still leaving us incompatible.
1. My original proposal was to make the semantics explicit in the
message. For example include a tag that stated "reversal" or
"restatement". This is how we traditionally model the semantics of a
message in FpML. This may not be the right way forward. Alternatives are:
1. Provide a state machine for each trade showing: which messages can
act upon the state and which can't, and which state it moves to. For
example OMGEO do this very successfully for CTM.
2. Additionally we might think about making the release notes and
examples normative.
3. Thirdly, we might revisit the use of CDL to specify message
exchanges.
2. Evenutally we will need in our protocols to demonstrate:
1. Deadlock freedom
2. Liveness
3. Resource management
4. Race Condition Detection
5. etc.
3. If we pursue FpML certification then we will need to specify the
process we want people to certify against.
4. In summary I propose:
1. We question really hard whether we want to embed this stuff in the
message.
2. We produce a State Transition Diagram for each of the major state
types.
3. We continue to monitor CDL and perhaps build a trial
implementation for one flow as an example.
Matthew Rawlings
Prime Brokerage Strategy & Architecture
+44 791 539 7824
Matthew D Rawlings
10/03/2005 17:34
To: mwg@xxxxxxxxxxxxxxxxxxxxxx
cc:
Subject: Re: FpML-MWG40 Messaging Framework Extensions to
support practical messagingLink
<Notes:///00256F190038F663//D962707D8B260F4580256FC0006016D7>
Hi Bob.
Yes, in the proposal it isn't backwards compatible with 4.1.
The agreement at the meeting on 3rd March 2005 is that the proposal should
be in the form of how we would do it if there were no backwards compatible
constraints. After reviewing the changes we would then discuss how to
compromise the solution to make it backwards compatible.
This process isn't consistently applied and isn't documented. I suggest
the process for making non backwards compatible contributions is
standardized and list in the FpML guide.
Matthew Rawlings
Prime Brokerage Strategy & Architecture
+44 791 539 7824
Robert Green <rgreen@xxxxxxxx>
09/03/2005 14:08
Please respond to mwg
To: mwg@xxxxxxxxxxxxxxxxxxxxxx
cc:
Subject: Re: FpML-MWG40 Messaging Framework Extensions to
support practical messaging
Matthew,
I'm interested in your thinking on why you made the <xsd:element
name="receiptsRequired"> element mandatory?
As I view it, the rest of the proposal does not break backwards
compatibility with the existing 4.1 FpML messaging architecture while
allowing the implementer to have more specificity over the message life
cycle if the partners choose to use the features. In the case of the
<receiptsRequired> element you have the usage as mandatory when, clearly,
there is use of the FpML messaging structures today without this element.
Your thoughts?
Bob
______________________________________
Bob Green
Vice President - Systems
Phone: 813 470-2800 FAX: 212 908-2255
Depository Trust & Clearing Corporation
18391 Bermuda Green Dr, Tampa FL 33647
matthew.d.rawlings@xxxxxxxxxxxx
03/07/2005 06:53 PM
Please respond to mwg
To: mwg@xxxxxxxxxxxxxxxxxxxxxx
cc: (bcc: Robert Green/DTCC)
Subject: FpML-MWG40 Messaging Framework Extensions to
support practical messaging
Dear All.
As discussed at last week's MWG meeting please find proposed extensions to
the Messaging Framework to support practical messaging.
There are 5 key areas fleshed out in this proposal:
1. Supporting multiple messageId
2. Making Reversals versus Restatements explicit
3. Conversations between Parties
4. Receipts beneath the business process but above the transport
level
5. Message Sources upstream of the sender
Here is a text overview:
An example message exhibiting much of this information:
The single changed xsd file.
As agreed in the meeting I am happy to discuss online.
Matthew Rawlings
Prime Brokerage Strategy & Architecture
+44 791 539
7824---------------------------------------------------------------------
To unsubscribe, e-mail: mwg-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: mwg-help@xxxxxxxxxxxxxxxxxxxxxx
---------------------------------------------------------------------
To unsubscribe, e-mail: mwg-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: mwg-help@xxxxxxxxxxxxxxxxxxxxxx
#### FpMLMessagingFrameworkExtensions.doc has been removed from this note
on March 13 2005 by Matthew D Rawlings
#### msg_ex016_msg_framework.xml has been removed from this note on March
13 2005 by Matthew D Rawlings
#### fpml-msg-4-2.xsd has been removed from this note on March 13 2005 by
Matthew D Rawlings
<<attachment: winmail.dat>>