- From: Amelia A Lewis <alewis@tibco.com>
- Date: Mon, 27 Sep 2004 14:01:36 -0400
- To: public-ws-desc-comments@w3.org
Answering in part as an editor of part two, but not on behalf of the WG. On Mon, 27 Sep 2004 10:35:04 -0700 michael.mahan@nokia.com wrote: > 1) Editorial - mismatched document scope > > Recommendation: revise Part 1 Introduction text, moving the abstract > text from Part 2 into the Intro of Part 1 for consistency and accuracy. That looks like an excellent idea. > 2) Clarification request in section 2 - 'Predefined Message Exchange > > Recommendation: Could you clarify the relationship between abstract WSDL > MEPs and SOAP bindings MEPs? An important aspect of the clarification is > the disposition of WSDL-defined faults (Fault Propagation Rules) in > light of the SOAP processing model. Note that we use, specifically, "fault propagation" rather than "fault generation" (which is what's in the SOAP processing model). Generation is up to whatever processing model is implementing the exchange pattern. Propagation is covered by the exchange pattern descriptions. Ws can try to clarify the relationship with the two SOAP MEPs (which both map to a single WSDL MEP, please note), but some of that sort of clarification properly belongs in part three, not part two. We have tried to clarify the characteristics that collectively differentiate one [WSDL] MEP from another in the definition that begins that section (predefined MEPs). Is it possible that, because the XMLP folks are so familiar with SOAP MEPs, that they have read this part with less openness? Clarifying the fault propagation rules with respect to the SOAP processing model (and its rules for fault generation) is nearly out of scope. I think we simply need to emphasize that these rules are about propagation, not generation, and indicate that generation rules are the domain of the processing model, whatever it may be. > 3) Editorial - sections 2.1.[12] > The cardinality of faults is raised, yet the patterns do not define > message cardinality. Perhaps this is an old artifact when message > cardinality was defined. > > Recommendation: remove references to message cardinality. Hmm, yes, looks like old stuff, pretty much. > 4) Editorial - section 3.1 Application Data Feature Glen, could you comment? Or maybe DavidO? Amy! -- Amelia A. Lewis Senior Architect TIBCO/Extensibility, Inc. alewis@tibco.com
Received on Monday, 27 September 2004 18:01:32 UTC