W3C home > Mailing lists > Public > xml-dist-app@w3.org > June 2000

SOAP spec. feedback (ambiguities, typos)

From: Daniel Barclay <Daniel.Barclay@digitalfocus.com>
Date: Wed, 14 Jun 2000 15:01:12 -0400
Message-ID: <3947D678.18730B6@digitalfocus.com>
To: xml-dist-app@w3.org

I've noticed a few typos and apparent ambiguities in the SOAP 
specification (at http://www.w3.org/TR/SOAP/ as of 2000-06-13):

Section 3:

- The last sentence says:

    That is, declaration in a DTD or schema with a default or 
    fixed value is semantically equivalent to appearance in an 

  However, several paragraphs earlier it says:
    A SOAP message MUST NOT contain a Document Type Declaration.  

  Should the mention of declaration in a DTD be removed, since
  there can't be a DTD, and that semantically equivalent case
  does not exist?

Section 4.4:

- The faultcode paragraph says:

    The faultcode element is ...  The faultcode MUST be present 
    in a SOAP Fault element and the faultcode value MUST be a 
    qualified name...

  The phrase "the faultcode value" is ambiguous.  It doesn't specify
  that the faultcode element contains just character data which is
  that faultcode value.

  (Note how it doesn't say where or how the qualified name actually 
  appears in the XML. Is it:
  - the value of some attribute on the element? 
  - the entire content of the faultcode element? 
  - the non-whitespace portion of the content? 
  - the immediately contained non-element content of the 
    faultcode element?)

Section 5.1:

- In the second numbered list, in item 8, paragraph 8 (counting the 
  BNF), says:

    For example, an array with 5 members of type array of integers 
    would have...

  It is unclear whether that refers to:
    an array that has 5 members and that is of type "array of integer"


    an array that has 5 members that are of type "array of integer"

Section 5.2:

- The third text pararaph says:

    ... whose type is either defined ... 
                          or is based ...

  That should be:

    ... whose type is either defined ... 
                          or based ...


    ... whose type either is defined ... 
                       or is based ...

Section 5.2.2:

- The first paragraph says "we spell-out..."; that should be "we 
  spell out..." (at least in US English; I don't know if UK English
  differs here).

Section 5.4:

- The first schema fragment says:

    <element name="Book">

  (Note the "</e:Book>" instead of "</element>".)

Section 5.4.2:

- The paragraph beginning "The element containing..." says:

    It may have any name, provided that the type of the element
    is either SOAP-ENC:Array or ...

  That might be ambiguous (between the _element_ type in the
  base XML sense and the _data_ type in the schema sense).

Section 5.6:

- The section refers to "serialization roots."  

  That term might be ambiguous.  It is not defined anywhere.
  (Is it meant to refer to "independent elements"?)

Section 7.1:

- The second bullet item says:

    The method invocation is viewed as a single struct containing 
    an accessor for each [in] or [in/out] parameter.  The struct is 
    both named and typed identically to the method name. 

  That second sentence is extremely ambiguous:  What exactly does 
  it mean for the struct's type to be identical to the method's type?
  Is the struct's type:

  - the type of the data that will be returned by the method?

  - a structure type composed of all the input parameters of the
    method, concatenated together, possibly in some specific order?

  - a method signature (that is, carrying input parameter type _and_
    return type information, like "typedef int FuncType(float);" in 
    C, if I can remember my C syntax)?

  Also, shouldn't that say "...named and typed identically to the 
  method" (instead of "...named and typed identically to the method 

P.S.  Wouldn't a complete word like "structure" or "record" be much
better than "struct"?  "struct" is a programming-language-specific 

Daniel Barclay
Digital Focus
Received on Wednesday, 14 June 2000 15:00:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:27 UTC