Marc, Irrespective of whether InfoPath or any other application supports type substitution, I think using type substitution in the Message Header is inordinately problematic and that is why I have submitted this proposal. You are correct in stating that in my proposal the content model (for the MessageHeader and Header) is always the same even though the message status changes. That is exactly the point. Why should you have to create a new MessageHeader type for any message function requirement? Why not just treat the message function as a value in an element? It dramatically simplifies a host of message processing requirements. Every methodology should be weighed in terms of its overall cost/benefits. Type substitution appears to be a low cost way to facilitate extensibility at the schema design stage. But the fact of the matter is it is extraordinarily costly (in terms of application design, development effort, application lifecycle maintenance, and application processing requirements) to support this methodology in real-world processes. That is why it is not a well supported feature in otherwise very robust XML centric development environments and applications. I am not suggesting that the entire FpML schema design methodology be revamped. Sometimes you have to live with what you start with. However, given that FpML B2B messaging is still in a seminal state it is a good opportunity to acknowledge the downstream costs of this methodology and to selectively make adjustments that are functionally pragmatic. I expected that this proposal would result in a lively dialogue and that is a good thing. Getting the FpML messaging framework to be functionally usable and viable within as many application contexts as possible will be critical to its success. As such it deserves a lot of scrutiny right now. I would certainly welcome hearing from people who are developing FpML B2B applications what there experiences are regarding the implementation of the messaging framework. Regards to all, Ira _____ From: Marc Gratacos [mailto:MGratacos@xxxxxxxx] Sent: Tuesday, March 15, 2005 2:02 PM To: mwg@xxxxxxxxxxxxxxxxxxxxxx Subject: RE: FpML-MWG40 FpML Messaging Framework Proposal and response to Matthew Rawling's proposed extensions Ira, I am not sure I agree with this proposal. It was the result of experimenting the use of the messaging framework with a tool that doesn't support type substitution at all. Personally I think we shouldn't stop using this mechanism (type substitution) just because a tool like InfoPath doesn't support it. It's my opinion. I agree that type substitution adds complexity to the schema and to implementations but we know that the content model may vary depending on the status of the message and type substitution facilitates that. In your proposal the content model is always the same even though you are changing the message status. Regards, -Marc _____ From: Ira Fuchs [mailto:ifuchs@xxxxxxxxxxxxxxxxx] Sent: Tue 3/15/2005 10:52 AM To: mwg@xxxxxxxxxxxxxxxxxxxxxx Subject: FpML-MWG40 FpML Messaging Framework Proposal and response to Matthew Rawling's proposed extensions To All Concerned, I am attaching a messaging framework proposal based on a collaboration with Marc Gratacos. Matthew Rawling's recent proposal to extend the messaging framework with a number of artifacts (Message ID, Reversal and Restatement, Conversations, Receipts and Sources) provided useful context in which to present this proposal and discuss its applicability and ramifications. Attached is a Word document containing the proposal followed by comments on Matthew's suggested extensions. Ira Fuchs XML Associates Inc. Phone: 718-268-0592 email: <mailto:ifuchs@xxxxxxxxxxxxxxxxx> ifuchs@xxxxxxxxxxxxxxxxx
<<attachment: winmail.dat>>