W3C home > Mailing lists > Public > xmlp-comments@w3.org > July 2002

FW: Last Call comments on SOAP 1.2 from the XForms WG

From: Micah Dubinko <MDubinko@cardiff.com>
Date: Mon, 29 Jul 2002 15:27:10 -0700
Message-ID: <E840F0B7E6189547BDB91DA8BF2228AB28C645@csmail.cardiff.com>
To: "'xmlp-comments@w3.org'" <xmlp-comments@w3.org>

The following are the comments from the XForms Working Group.
These comments are divided into three categories.
1) Substantive.
2) Readability. We consider these important comments, and request changes to
the specification.
3) Minor Editorial. For these minor issues, we leave it to the discretion of
the editors to make necessary changes.


a) [Part0 3. Using various protocol bindings]
"...an encrypted form." Can you clarify in the text whether you mean 'a
fill-out form' vs. "the mode in which a thing exists"? [dictionary.com]

b) [Part0 3.1.1. SOAP HTTP GET usage]
Please mention that to use an XML SOAP envelope as XForms external instance
data, HTTP GET usage (SOAP Response Message Exchange Pattern) is required.
At the editors' discretion, you might also mention other similar cases, such
as document() in XSLT, etc.

c) [Part1 5. SOAP Message Construct]
May a SOAP infoset legally contain comment information items? If yes, where?
Please clarify.

d) [Part1 5.3.1 SOAP Body child Element]
Child elements "MUST have a [namespace name] property which has a value,
that is, be namespace qualified." We request removing this restriction for
the following reason:
Many XML Forms use non-namespaced instance data, and we expect SOAP to
become a common source of instance data for such Forms. Thus, a requirement
for namespaces would put an unnecessary burden on adoption of both SOAP and

e) [Part1 5.4.6 SOAP Fault Codes]
Please change the name of the "DataEncodingUnknown" fault code to the more
accurate "SOAPEncodingUnknown".

f) [Part1 5.4.8 SOAP mustUnderstand Faults]
The name "Misunderstood" suggests that the processor incorrectly attempted
to do something. "NotUnderstood" is a more accurate name.

g) [Part1 6. Use of URIs in SOAP]
"SOAP receivers SHOULD be able to deal with URIs of at least 2048 characters
in length"
We request that this be a MUST requirement.

h) [Part1 A. Version Transition From SOAP/1.1 to SOAP Version 1.2]
This section states that SOAP nodes receiving SOAP/1.1 messages either:
1 "MAY process the message as a SOAP/1.1 message (if supported), or"
2 "MUST generate a version mismatch SOAP fault based on a SOAP/1.1 message
construct following SOAP/1.1 semantics."
Either way, a reference to SOAP/1.1 ([19] in the current document) is
required. Since that appendix is not specifically marked "non-normative",
the reference would have to be normative, and thus all conforming SOAP/1.2
processors also must implement a portion of SOAP/1.1. Please ensure that
conformance to this section of SOAP/1.1 is considered a "feature" for
purposes of exit criteria.

i) [Part2 Sections 2-4 & Appendix A (re: SOAP encoding and RPC
We request that these optional sections be moved into a separate document.
We note the success with which XHTML, SVG, CSS, and XPointer have done
similar modularization.

As written, these optional sections contain optional subsections (and even
required subsections), which is unnecessarily complex. As a separate
document, the conformance requirements for RPC SOAP can be more clearly
spelled out, and the result will be smaller, simpler SOAP specifications.

j) [Part2 2.3 Values]
We agree with the editorial note which suggests removing "generics".

k) [Part2 itemType Attribute Information Item]
Please change the name of this to "childItemType".

l) [Part2 ref Attribute Information Item]
Please change the name of this to "idref". This not only more closely
represents the type of the attribute (xs:IDREF), but also avoids cognitive
dissonance with the XForms attribute 'ref' (which bears an XPath

m) [Part2 3.2 Decoding Faults]
id->idref constraint violations are serious problems. Please change 'SHOULD'
to 'MUST' on the requirement to signal a fault under these conditions.


n) [Part2 2.1 Graph Edges & 2.2 Graph Nodes]
In the above sections, please provide an examples of non-XML data
structures, such as a 'struct' and 'array' from a programming language, and
how these map to abstract nodes and edges, or alternately include a
hyperlink to such examples in a separate document.

o) [Part2
  3.1.1 Encoding graph edges and nodes &
  3.1.2 Encoding simple values &
  3.1.3 Encoding compound values &
  3.1.4 Computing the Type Name property &
  3.1.5 Unique identifiers &
  3.1.6 arraySize Attribute Information Item]
For each of the above sections, please include at least one example, or
alternately include a hyperlink to an example in a separate document.

p) [Part2 3.1 Rules for encoding Graphs in XML]
"The encodings are described below from the perspective of a de-serializer."
Not only does this point of view conflict with the section name, it also
makes understanding the encoding unnecessarily difficult. Please re-write
this section from the point of view of an XML serializer.

q) [Part2 3.1.1 Encoding graph edges and nodes]
The first sentence of this section is strongly worded, and suggests that
element information items *only* represent edges, when in fact they at times
represent a combined edge and node. (for example in the first sentence of
3.1.3) Please correct this.
Bullet 4 mentions "a graph edge [that] does not terminate in a graph node".
This is confusing, and seemingly in conflict with the first sentence in 2.1:
" Edges in the graph are said to originate at a graph node and terminate at
a graph node."


[Throughout] When referring to XML Schema datatypes, please use the more
compact notation 'xs:anyURI' instead of 'anyURI in the namespace named

[Throughout] Please use textual instead of numeric identifiers for
references ( [HTTP 1.1] instead of [2]) This applies to parts 0-2.

[Part1 8. References]
The following reference seem to be "orphaned" (not referred to from
[9] (XLink) Please remove the reference.

[Throughout] Please ensure that infoset property names and values have a
distinguishing typographical style.
(Example: "A specified property..." should be "A [specified] property...")
Received on Monday, 29 July 2002 18:27:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:16:59 UTC