(Mostly editorial) comments on the 9th July 2001 draft

Note that some of those reported "problems" have disappeared with the
infoset-ization of the specification (version $Date: 2001/07/18
21:21:50 $).

- Section 1.3: Example 1

It would be preferable to use www.example.org for the example instead
of www.stockquoteserver.com.

- Section 2.3

I don't remember where I got this from, but I think that from a
stylistic point of view, we should avoid the use of "we":

   We say that a SOAP block is targeted to a SOAP node if the SOAP actor
   (if present) on the block matches (see [8]) a role played by the SOAP
   node, or in the case of a SOAP block with no actor attribute
   (including SOAP body blocks), if the SOAP node has assumed the role of
   the anonymous SOAP actor.

 ->

   _A SOAP block is said to be_ targeted to a SOAP node...

- Section 2.4

Same comment:

   We presume that specifications for a wide variety of header functions
   will be developed over time, and that each SOAP node MAY include the
   software necessary to implement one or more such extensions. We say
   that a SOAP header block is understood by a SOAP node if the software
   at that SOAP node has been written to fully conform to and implement
   the semantics conveyed by the fully qualified name of the outer-most
   element of that block.

 ->

   _Specifications for a wide variety of header functions are expected
   to be developed over time, and it is expected_ that each SOAP node
   MAY include the software necessary to implement one or more such
   extensions. _A SOAP header block is said to be_ understood...

- Section 2.4

   When a SOAP header block is tagged with a SOAP mustUnderstand
   attribute with a value of "1"...

mustUnderstand is a xsi:boolean. which is described in the schema
spec[61] as true or false. I am not sure how to phrase that, but "1"
is too restrictive. Maybe:

   When a SOAP header block is tagged with a SOAP mustUnderstand
   attribute whose value is true...

FIXED in the infoset version.

- Section 2.5

    1. Generate a single SOAP mustUnderstand fault if one or more SOAP
       blocks targeted at the SOAP node carry the attribute
       env:mustUnderstand="1" and are not understood by that node.

Same comment about the value of a boolean.

FIXED in the infoset version.

- Section 4.1.2

Since this section talks about versioning, I think that it should be
clear that it talks about SOAP Version 1.2, especially because it
mentions SOAP/1.1:

   SOAP does not define a traditional versioning model based on major
   and minor version numbers. A SOAP message MUST contain a SOAP
   envelope associated with the
   "http://www.w3.org/2001/06/soap-envelope" namespace. If a SOAP
   message is received by a SOAP node in which the SOAP envelope is
   associated with a different namespace, the SOAP node MUST treat
   this as a version error and generate a VersionMismatch SOAP fault
   (see section 4.4). A SOAP VersionMismatch fault message MUST use
   the SOAP/1.1 envelope namespace
   "http://schemas.xmlsoap.org/soap/envelope/" (see Appendix C).

 ->

   SOAP does not define a traditional versioning model based on major
   and minor version numbers. A SOAP _Version 1.2_ message MUST
   contain a SOAP envelope associated with the
   "http://www.w3.org/2001/06/soap-envelope" namespace. If a SOAP
   message is received by a SOAP _Version 1.2_ node in which the SOAP
   envelope is associated with a different namespace, the SOAP node
   MUST treat this as a version error and generate a VersionMismatch
   SOAP fault (see section 4.4). A SOAP VersionMismatch fault message
   MUST use the SOAP/1.1 envelope namespace
   "http://schemas.xmlsoap.org/soap/envelope/" (see Appendix C).

- Section 4.4.1

The boolean problem:

   An immediate child element of the SOAP Header element that was
   either not understood or not obeyed by the processing party
   contained a SOAP mustUnderstand attribute with a value of "1" (see
   section 4.2.3)

_NOT_ FIXED in the infoset version.

- Section 5.1

I reread this section and found it... hmmm... discouraging :-) without
any examples. Moreover, most of the things said there are repeated
later; e.g. the definition of arrays (point 8) could be moved to
section 5.4.2.

I don't know how people feel about section 5, but we could rearrange
stuff IMHO. If I am not the only one with this opinion, I would be
happy to see an issue created about this.

  61. http://www.w3.org/TR/xmlschema-2/#boolean
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/ - tel:+1-617-452-2092

Received on Wednesday, 25 July 2001 13:32:56 UTC