Re: Comments from a Read-Through of Part 1

Noah Mendelsohn/Cambridge/IBM wrote:

> 
> ** The second paragraph of section 1.4 "Robustness Principle" suggests that
> our specification in all cases provides conservative values, but that the
> robustness principle suggests that some unspecified broader set of values
> should also be accepted.  While I like the robustness principle, I am
> concerned about this formulation.  I think that in all cases we should
> specify precisely what must be sent and what must be accepted.  In doing
> so, we will often obey the robustness principle, and will indeed specify
> that a receiver MUST accept values that a legal sender SHOULD NOT send.  I
> do not think we should ever be vague about what a conforming receiver
> should except.  Specifically, I would propose the following as a
> replacement for the second paragraph: "The robustness principle is applied
> for several purposes within this recommendation.  For example, section
> 5.2.2 provides that senders SHOULD NOT send but receiver's MUST accept
> certain values of the role attribute."
> 

Done, but text from the original paragraph describing the equivalence of 
lexical forms of attribute values (e.g. "1" equivalent to "true" for 
boolean) is retained for now in a separate paragraph added to section 1.2.


> ** Section 1.2 second paragraph:  now says:  "all information items defined
> by this specification are identified using XML namespace names".  That's
> not true.  For example, the faultcode element is unqualified.  We should
> either consistently qualify everything, or else change this statement in
> section 1.2.
> 

Done, as a quick fix i have changed to "Some of the information 
items...". I believe we discussed qualifying all elements a while ago 
and decided against ?


> ** Section 2.8, first paragraph: the reference at the end of the paragraph
> is wrong.  It should be a reference to the section on extensibility, not to
> the section on processing SOAP messages. In general, I think the wording
> and presentation of this section could use a bit of cleanup.
> 

Done.


> ** Section 5, first paragraph: the reference at the end of the first
> paragraph is to the section in which the paragraph appears.
> 

Done.


> ** Section 5: the last paragraph suggests that within any element defined
> by this specification, whitespace character children are insignificant.  Is
> this true for all of our fault elements, for example?  What about
> FaultString?  I'm not expert enough on infoset, but I would expect that
> fault strings can have significant whitespace.
> 

Done for fault string and detail entry (not detail). Are there any other 
elements we define where whitespace is significant ?


> **Section 5: in general, is there any ambiguity as to whether namespace
> declarations, xsi:type, and other such attributes may appear on SOAP
> constructs?  (see also comment immediately below)
> 
Not done, see next item.

> ** Section 5.1: in the description of the envelope attribute information
> item, we say "zero or more namespace qualified attribute information
> items".  This vaguely suggests that user-defined qualified attributes may
> be supplied in addition to those from our specification.  If the schema for
> SOAP is normative (I don't remember whether it is) that might settle the
> question, but in any case I think the wording could be more clear.  Similar
> comments would apply to the definitions of many other elements in chapter
> 5.
> 
Not done. The schema says the same thing as the text - do we want to change ?

> ** Section 5.2.2: and/or section 2.3: do we state anywhere what the
> comparison rules are for URI's used as role attributes?  Keep in mind that
> in general on the web, such comparison rules are determined by the URI
> scheme.  In the case of HTTP, case is not significant.  I think we want to
> be clear that, as with XML namespaces, what we have in mind is straight
> string comparison.  There's no way we want a SOAP processor to have to know
> all the rules for a wide variety of schemes.  ...closely related to the
> following proposal on section 6.0:
> 
Not done, see next item.

> ** Section 6.0:  This section provides general information on the use of
> URI's in SOAP, and specifically says:  "SOAP does not define any
> equivalence rules for URIs in general as these are defined by the
> individual URI schemes and by RFC 2396 [6]. However, because of
> inconsistencies with respect to URI equivalence rules in many current URI
> parsers, it is RECOMMENDED that SOAP senders do NOT rely on any special
> equivalence rules in SOAP receivers in order to determine equivalence
> between URI values used in a SOAP message."  In the case of role name
> URI's, I think this is much too vague to guarantee interoperability.  For
> example, it implies that an http URI used in a role attribute might come
> back uppercased in a faultRole report, or that a role name of http://abc
> might match http://aBc.   I suggest the following replacement for the
> paragraph in question:  "SOAP does not in general define any equivalence
> rules for URIs, except when used as the value for attributes defined in
> this recommendation.   Where this recommendation calls for comparison with
> attribute values of type anyURI  (e.g. when determining whether a node acts
> in a role), equality is defined as identity of the sequence of character
> information items comprising the attribute value.  Similarly, when a URI is
> to be copied from one message to another (e.g. when a faultRole is
> reported), an exact copy of the the characters MUST be supplied."
> 
Not done, sounds OK to me - Henrik I think you wrote that section ?

> **Section 5.2.3, last paragraph: Current version: "If relaying the message,
> a SOAP intermediary MAY substitute a non-canonical value with the canonical
> value "true" and MAY omit the SOAP mustUnderstand attribute information
> item if the value is "false" or "0"."   Proposed replacement: "If relaying
> the message, a SOAP intermediary MAY substitute "true" for the value "1",
> or "false" for "0".  The SOAP mustUnderstand attribute information item may
> be omitted if its value would have been "false" or "0"."  The original
> seemed to suggest that a non-canonical value for false (i.e. "0") could be
> replaced by the canonical value "true".
> 
Done.

> **Section 7.0 (Security Considerations): I strongly feel that this section
> should be nonnormative and should be moved to an appendix.  It is strictly
> advisory, and has essentially no testable assertions.  The possible
> exception is section 7.3.1 which is on the use of ports.  If we want to
> keep that in the main portion of the text, I suggest we move it to the
> binding framework.  I also suggest that a bit more editing be done on
> section 7, as the concepts are subtle and it's not always clear what's
> really intended.
> 
Not done, I support the suggestion to move it to a non-normative appendix - any argument against ?

Regards,
Marc.


-- 
Marc Hadley <marc.hadley@sun.com>
XML Technology Centre, Sun Microsystems.

Received on Friday, 5 April 2002 09:46:50 UTC