Brock, Yes, I am proposing that the "allocations" element be moved up a level. I might be missing something here but I don't understand why not replicating the trade documentation for each allocation instance (and using a reference to the trade) would diminish readability. Given the already large number of nested elements and attributes in FpML I am a strong proponent of keeping things as simple and as flat as possible. I don't think the Trade needs to be extended for allocation-level approval, just add an approval element to the allocation element. Regards, Ira _____ From: Arnason, Brock (FID) [mailto:Brock.Arnason@xxxxxxxxxxxxxxxxx] Sent: Monday, February 28, 2005 11:09 AM To: mwg@xxxxxxxxxxxxxxxxxxxxxx Subject: RE: FpML-MWG40 Client Account Proposal Ira, 1. If I understand you correctly, you're proposing that the "allocations" element be moved up a level. Also, the long form would contain references to sibling trades instead of an enclosed set of fully expanded trades. The short form would remain unchanged. I understand this is closer to the existing FpML convention for representing a portfolio of trades. In fact, that is how I originally structured the proposal. However, it significantly reduces prima facie readability. We can discuss in the meeting - if there's a good argument for backward compatibility to be made, I'm amenable to change. 2. Point taken. This would be straightforward to add to the "short form". Would you propose extending the Trade to add allocation-level approval for the long form? Sincerely, Brock _____ From: Ira Fuchs [mailto:ifuchs@xxxxxxxxxxxxxxxxx] Sent: Monday, February 28, 2005 8:52 AM To: mwg@xxxxxxxxxxxxxxxxxxxxxx Subject: RE: FpML-MWG40 Client Account Proposal Mr. Arnason (and Messaging Work Group members), I reviewed your allocation proposal documentation and I have some questions and suggestions: One - Would your functional objectives be met by simply creating an allocations group that was a sibling of trade and contained multiple allocation elements? Each allocation element would contain a reference to the trade. In this way a confirmation could be generated for each allocation without having to replicate the entire trade documentation for each allocation instance. It would also eliminate the need to have multiple trade types defined. Two - The existence of approval status elements has a conditional implication for the status of the Allocation itself. Consequently should there be an Allocation status element as well? Regards, Ira Fuchs XML Associates Inc. Phone: 718-268-0592 email: <mailto:ifuchs@xxxxxxxxxxxxxxxxx> ifuchs@xxxxxxxxxxxxxxxxx _____ This is not an offer (or solicitation of an offer) to buy/sell the securities/instruments mentioned or an official confirmation. Morgan Stanley may deal as principal in or own or act as market maker for securities/instruments mentioned or may advise the issuers. This is not research and is not from MS Research but it may refer to a research analyst/research report. Unless indicated, these views are the author's and may differ from those of Morgan Stanley research or others in the Firm. We do not represent this is accurate or complete and we may not update this. Past performance is not indicative of future returns. For additional information, research reports and important disclosures, contact me or see https://secure.ms.com/servlet/cls. You should not use e-mail to request, authorize or effect the purchase or sale of any security or instrument, to send transfer instructions, or to effect any other transactions. We cannot guarantee that any such requests received via e-mail will be processed in a timely manner. This communication is solely for the addressee(s) and may contain confidential information. We do not waive confidentiality by mistransmission. Contact me if you do not wish to receive these communications. In the UK, this communication is directed in the UK to those persons who are market counterparties or intermediate customers (as defined in the UK Financial Services Authority's rules).
<<attachment: winmail.dat>>