I have been following this discussion with interest and it seems to me that several different ideas are being mixed together instead of each being considered on its own merits. 1. The business process around amendments and cancelations is unclear. In my experience whether an institution sees a amendment as a single thing or as a cancellation and rebooking is normally determined by how its systems work and how the change is detected and exported to other systems. Both techniques achieve the same end state but with cancel and rebook is it possible that the relationship between the two actions is lost. The same is true of events such as option exercise. FpML should have a preferred technique (in my opinion an amend message) but I suspect that some firms may not be able to get away from the cancel/rebook approach for systemtic reasons. 2. I am unclear why Matthew sees a requirement to add additional receipts. Many transports provided this kind of information as part of thier operation. Any if more sophistication is required then maybe he should insert another encapsulation standard such as ebXML in his stack rather than over complicate FpML. I need to speak to him to understand his reasoning better. 3. Several alternative modules were considered during the design of the messaging framework. We preferred the current approach of defining a type of for each message because it means that the payload of each message can be customised to suit is purpose. Whilst the approach you suggest means that the schema does not have to be changed to add a new message type or 'action' it does entail the writing of validation code in each processor to ensure that the content of a more generic document is appropriate to a specific action. Using the schema to do a 'coarse' validation of the content is an easy way of ensuring that all processing implementations get a consistent initial level of validation. 4. Many companies involved in XML tool creation (my own included) are see XML as a file format for persisting Java and C# languages and only support the OO friendly features of the language. This is a big mistake. We are trading products today using FpML that will not mature for 15-30 years. Java and C# will be distant memories when these deals matures but the XML will remain the legally binding contract definition. Type substitution, complex type extension/restriction and substitution groups are the key features of XML supporting extensibility in models. Many of the 'opinions' on the internet regarding thier usefullness come from people working in 'commercial' domains with more static information models. They do not have to deal with models where products and processes change on a regular basis. Indeed this is the problem with standards such as ISO 20022 which are designed from the point of view of the settlement process and centralised governance models. Andrew Jacobs, Senior Consultant, Financial Markets IBM UK Ltd., 76 Upper Ground, London, SE1 9PZ, UK e-mail: andrew_jacobs@xxxxxxxxxx Tel: +44(0)20 7202 3861 -- Fax: +44(0)20 7202 5774 -- Mobile: +44(0)7710 304239 "Ira Fuchs" <ifuchs@xxxxxxxxxxxxxxxxx> 15/03/2005 21:20 Please respond to mwg To <mwg@xxxxxxxxxxxxxxxxxxxxxx> cc Subject RE: FpML-MWG40 FpML Messaging Framework Proposal and response to Matthew Rawling's proposed extensions All, To keep things lively I invite you to peruse the following regarding type substitution. I believe that we should avoid using type substitution in the Message Header. I look forward to any and all comments and suggestions. http://www.xml.com/pub/a/2003/10/29/derivation.html http://www.xfront.com/ExtensibleContentModels.html http://serv4.itsware.net/bb/viewtopic.php?t=671&; http://pluralsight.com/blogs/tewald/archive/2004/08/20/1982.aspx Ira Fuchs XML Associates Inc. Phone: 718-268-0592 email: <mailto:ifuchs@xxxxxxxxxxxxxxxxx> ifuchs@xxxxxxxxxxxxxxxxx --------------------------------------------------------------------- To unsubscribe, e-mail: mwg-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx For additional commands, e-mail: mwg-help@xxxxxxxxxxxxxxxxxxxxxx
<<attachment: winmail.dat>>