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
<<attachment: winmail.dat>>