Re: WSDL 1.2: Updated draft (June 30) - typos and minor errors

Kevin, thanks for pointing these out. I've have left the most controversial
ones, done the others.

Jean-Jacques.

"Liu, Kevin" wrote:

> MINOR/EDITORIAL ERRORS
> >>>Section 2 (text above the box for "issue-require-targetnamspace")
> indicates that targetNamespace is required, whereas section 1.2 (if we
> decide to keep it) the grammar still shows that defintions@targetNamespace
> is optional --- the ? after targetNamespace should be removed

Done. Well spotted.

> >>>Section 2 (text above the box for "issue-require-targetnamspace")  the
> new text for targetNamespace is not very clean - maybe just for me. I
> believe the resolution is to make defintion@targetNamespace required. All
> children elements defined by this wsdl document belongs to this namespace. I
> know we are talking about abstract model here, but if map to the wsdl
> elements, the wording reads like wsdl1.2 requires that every individual
> child elements, except type element,  have a targetNamespace attribute. I
> don't believe that's what we meant.
>
> Again, this may be just my own interpretation, other people may interpret
> differently. To avoid future confusion,  can we make the wording more
> straight-forward?

I think you're right, this needs rewording. NOT done.

> >>>Section 2.3 paragraph 9 bullet 1 say "...one of the zero or more fault
> messages MUST...". It sounds a little weird in the case of zero, should it
> be changed to "...one of the listed fault messages MUST..."?

Changed to:
<replacement>
  The semantics
  are that when the input message is sent to the service, one of the
  following MUST happen: the output message is generated; or one of the
  fault messages listed is generated instead. It is an error for both
  an output message and a fault message to be generated in response
  to the same input message.
</replacement>

I think at some point we will need to get our terminology straight. For example,
how do we name an endpoint? a service (like above), an endpoint (elsewhere in
the spec), or an (ultimate) receiver (like in SOAP)? Is a message simply sent,
or received and processed? Is an output message generated or sent back in
response to a request? etc.

> >>>Section 2.6  indicates that "A service description component MUST contain
> one or more port descriptions", whereas section 1.2 (if we decide to keep
> it) the grammar shows that service may have zero or more port - the symbol *
> should be changed to +

Done.

> >>>Section 2.6 needs some clean up. There are some paragraphs duplicate or
> even contradict with each other. For example, paragraph 4 and 6 both state
> for port@name but makes different statements. paragraph 5 and 7 both refer
> to "binding" property- seems paragraph 5 is wrong by saying "service" has a
> binding property

NOT done.

> >>>section 4 optional @required for extensibility elements- If I remember
> right, the WG agreed that the value of this attribute is "false". Should it
> be explicitly reflected in the spec?

Done. Added an extra sentence:
<addition>
Omitting this AII is defined as being semantically equivalent to including it
with a value of false or 0.
</addition>

> TYPOS
>
> >>> section 2.2, paragraph 3: "a atomic entity" should be changed to "an
> atomic entity"

Done.

> >>> section 2.2 paragraph 6: "if a type system other that XML Schema..."
> should be changed to "if a type system other than XML Schema..."

Done.

> >>> section 3.2 paragraph 1: "WSDL uses the optional document elements..."
> should be changed to "WSDL uses the optional documentation elements...". In
> the last sentence of same paragraph, the font of "documentation" should be
> changed to italic to be consistent with the rest of the spec

Done both. Again, well spotted.

> >>>section 3.3 paragraph 1, "by separationg the definitions ..." should be
> changed to "by separating the definitions..."

Couldn't find this one. NOT done.

> I didn't dig into all sections for typos, you may just want to run a spell
> check before publishing the spec.

Done.

Thanks again,

Jean-Jacques.

Received on Tuesday, 2 July 2002 10:38:47 UTC