RE: QA Review on WSDL 2.0 Part 1, intro and conformance issues

At our recent FTF, we resolved most of your remaining comments as detailed below.  We will assume you accept these resolutions if we don't receive an explicit acknowledgement by 1 October.

> -----Original Message-----
> From: public-ws-desc-comments-request@w3.org [mailto:public-ws-desc-
> comments-request@w3.org] On Behalf Of Dominique Hazaël-Massieux
> Sent: Thursday, August 05, 2004 5:48 PM
> To: public-ws-desc-comments@w3.org
> Subject: QA Review on WSDL 2.0 Part 1, intro and conformance issues

> * Processor conformance
> http://www.w3.org/TR/2004/WD-wsdl20-20040803/#processor
> """This section defines a class of conformant WSDL processors that are
> intended to act on behalf of a party that wishes to make use of a Web
> service"""
> I suggest that you give a specific label to this class of WSLD
> processors, à la "WSDL 2.0 requesting processor" - you'll probably find
> something better.

We agreed to reword the paragraph to remove "class" distinctions (since we only define one class) as follows:

'This section defines conformance of a WSDL processor. In this section, the term "WSDL processor" refers to a processor that is acting on behalf of a party that wishes to make use of a Web service (i.e., the requester entity or requester agent, rather than the party that implements the Web service (i.e., the provider entity or provider agent).'

[See http://www.w3.org/2002/ws/desc/4/lc-issues/#LC5d]

> * "a conformant WSDL processor MUST accept any legal WSDL document":
> what is a legal WSDL document? I suggest saying "conformant WSDL
> document" - but I'm still unclear whether you define that at all in the
> section above

We agreed we're a bit lax on our terminology here.  We agreed to add a definition of WSDL Document as a wsdl:definitions element and its descendents.  This would likely appear in the notational conventions section (1.3) and section 8.1 can be simplified accordingly.  We also agree to change "legal" to "conforming" wsdl document.

[See http://www.w3.org/2002/ws/desc/4/lc-issues/#LC5e]

> * you use both the expressions "a processor MUST fault" and "a processor
> MUST fail"; do they mean the same thing? In any case, I think you should
> clarify what is meant by those (i.e. what consist failing/faulting in?),
> and if they mean the same thing, only use one of the expressions; also,
> since the name 'fault' is used in a very well defined context in the
> spec, I think you should avoid using the verb 'fault' unless it relates
> to the said context; more generally, I think developing the notion of
> error handling for a WSDL processor would be benefitial

(no resolution as yet.)

[See http://www.w3.org/2002/ws/desc/4/lc-issues/#LC5f]


> * "a conformant WSDL processor MUST either agree to fully abide": I
> think this an abusive usage of MUST, since "agreeing" is not an
> operation that a WSDL process does; I would suggest "a conformance WSDL
> processor MUST immediately cease processing (fault) if it doesn't agree
> to fully abide ...."

We accepted your suggestion.

[See http://www.w3.org/2002/ws/desc/4/lc-issues/#LC5g]

> * "that it does not choose to implement." -> "it chooses not to
> implement", or maybe "it doesn't implement"

Reclassified as editorial.  No final resolution yet.

[See http://www.w3.org/2002/ws/desc/4/lc-issues/#LC5h]

> * the "Note:" under this defines conformance requirements for a provider
> agent, which is out of scope for the given section; I suggest creating a
> different section, even if that's the only requirement for it

We agreed to delete the note from the conformance section (as redundant), promote the material on optional extensions into its own section, and add "See section ___ for further explanation".

[See http://www.w3.org/2002/ws/desc/4/lc-issues/#LC5i]

> * the section 6.1 on mandatory extensions adds requirements both for
> requesting and providing processors; most are duplicated in the
> conformance section, but I think a few are not (e.g. "the provider agent
> MUST support every extension, Feature or Property that is declared as
> optional in the WSDL document"); I suggest they should be added to the
> conformance section
> http://www.w3.org/TR/2004/WD-wsdl20-20040803/#mandatoryext

We believe the resolution to LC5i addresses this issue as well.

[See http://www.w3.org/2002/ws/desc/4/lc-issues/#LC5j]

> *likewise, section 4.1 makes a suggestion for processors:
> "Processors are encouraged to keep track of the source of component
> definitions, so that multiple, mutual, and circular includes do not
> require establishing identity on a component-by-component basis."
> http://www.w3.org/TR/2004/WD-wsdl20-20040803/#includes
> Maybe this could be added as a SHOULD in the conformance section

This text is only intended as advice to implementers. We agreed to delete it.

[See http://www.w3.org/2002/ws/desc/4/lc-issues/#LC5k]

> * section 1.1 reads "All parts of this specification are normative, with
> the EXCEPTION of notes, pseudo-schemas, examples, and sections
> explicitly marked as "Non-Normative"."; some of the "Note:"s include
> normative-like language, e.g.
> "Support for the W3C XML Schema Description Language [XML Schema:
> Structures],[XML Schema: Datatypes] is required of all processors."


The intent is that this statement reinforce the conformance requirement stated in the conformance section.  As such, the Working Group didn't want to promote or delete the note, instead clarifying that it is simply a forward reference by changing "processors" to "conformant processors", and linking to the conformance section.

> or
> "If a WSDL document declares an extension or feature as optional, then
> if that extension or feature could apply to messages sent by the
> provider agent as well, then the provider agent MUST NOT send any
> messages that requires the requester agent to support that extension or
> feature."
> Please fix.

The Working Group agreed to make the Note in 6.3 normative, and rephrase as "Extensibility elements SHOULD NOT alter the existing semantics in ways that are likely to confuse users."

[See http://www.w3.org/2002/ws/desc/4/lc-issues/#LC5l]


Thanks again for your comments.

Received on Tuesday, 21 September 2004 18:21:56 UTC