- From: John Ibbotson <john_ibbotson@uk.ibm.com>
- Date: Thu, 15 Nov 2001 09:47:02 +0000
- To: "Nilo Mitra (EMX)" <Nilo.Mitra@am1.ericsson.se>
- Cc: xml-dist-app@w3.org
Nilo, Comments below. I have added a number of example messages to the document which should provide more illustrations. As promised on the call yesterday, I'll make sure the draft is "complete" before the F2F. John XML Technology and Messaging, IBM UK Ltd, Hursley Park, Winchester, SO21 2JN Tel: (work) +44 (0)1962 815188 (home) +44 (0)1722 781271 Fax: +44 (0)1962 816898 Notes Id: John Ibbotson/UK/IBM email: john_ibbotson@uk.ibm.com "Nilo Mitra (EMX)" <Nilo.Mitra@am1.er To: John Ibbotson/UK/IBM@IBMGB icsson.se> cc: xml-dist-app@w3.org Subject: RE: Usage Scenarios 11/14/2001 09:23 PM Please respond to "Nilo Mitra (EMX)" John: Here are some comments on the usage scenario descriptions ([1]): 1. Should we not make a global change from "XMLP" to "SOAP", or "SOAP 1.2"? <JBI> Agreed - changed XMLP to SOAP in text and all diagrams 2. Section 2.1.2, last sentence: This is the *only* place where "XMLP_UNITDATA.send" is used. I would delete it, as it is does not really add much to the discussion and you don't want to get caught up explaining the additional terminology. <JBI> Agreed - I've deleted the last sentence 2bis. Section 2.4.2., first para: This talks of "XMLP Handlers". I'm not sure this is a defined concept, and the text following about the handlers being required to do the parameter and result serialization seem too prescriptive. <JBI> I've changed this section in line with the RPC examples where the Body is used for the request arguments and result 3. Text immediately following Fig. 5: "For the RPC programming model, an RPC Request handler on the XMLP Sender serializes the calling parameters and places them in an XMLP Header in the calling request." This seems too prescriptive. <JBI> Replaced with example RPC request/response messages 4. Same place, the very next sentence: " The XMLP Receiver has a matching XMLP Handler which extracts the serialized parameters and invokes the procedure (which is local to the XMLP Receiver).". Can one be sure of the statement in parentheses? Is that statement necessary? <JBI> Replaced and simplified with examples 5. Section 2.5.2. Why is a transport supporting the request/response assumed? This could equally well have been provided by two unidirectional messages. Is it necessary to have a status block generated for the request/response scenario? For example, a HTTP POST can be acknowledged with a "202" or "204" status code (and no response body) could serve equally well for this scenario. <JBI> Scenario S5 specifically requires an acknowledgement request of some kind and I've interpreted this as being independednt of any underlying transport ack. Reliable delivery and date/time of delivery is the example I've used. I agree that two unidirectional messages could be a solution, but that is the case for all of the scenarios so in this case I simply assumed an HTTP type of transport - I don't then have to add a correlation header. I'll provide others as I go through it some more later. Better to get this partial review out to you sooner rather than be complete - and late. Best regards Nilo [1] http://www.w3.org/2000/xp/Group/1/10/18-us/XMLProtocolUsageScenarios Nilo Mitra Ericsson Internet Applications Inc. phone: +1 516-677-1073 mobile: +1 516-476-7427 email: nilo.mitra@ericsson.com -----Original Message----- From: John Ibbotson [SMTP:john_ibbotson@uk.ibm.com] Sent: Friday, October 19, 2001 10:18 AM To: xml-dist-app@w3.org Subject: Usage Scenarios The latest draft of the usage scenario descriptions is available from http://www.w3.org/2000/xp/Group/1/10/18-us/XMLProtocolUsageScenarios Please can you review it and provide feedback. The remaining scenarios will be added asap. John XML Technology and Messaging, IBM UK Ltd, Hursley Park, Winchester, SO21 2JN Tel: (work) +44 (0)1962 815188 (home) +44 (0)1722 781271 Fax: +44 (0)1962 816898 Notes Id: John Ibbotson/UK/IBM email: john_ibbotson@uk.ibm.com
Received on Thursday, 15 November 2001 04:56:57 UTC