W3C home > Mailing lists > Public > public-ws-desc-comments@w3.org > September 2004

Re: XMLP Review of WSDL 2.0 Part 2 LC WD

From: Amelia A Lewis <alewis@tibco.com>
Date: Mon, 27 Sep 2004 14:01:36 -0400
To: public-ws-desc-comments@w3.org
Message-id: <20040927140136.2322e6f2.alewis@tibco.com>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:31 GMT