W3CArchitecture DomainXML Protocol WG

Feedback on SOAP 1.2 Recommendation

Last update: $Date: 2007/06/20 19:29:10 $

Issues regarding the documents produced but the XML Protocol Working Group should be reported to xmlp-comments@w3.org (public archives).

Comments on this list should be sent to the xml-dist-app@w3.org mailing list (Archives).

For the previous list of closed issues, you can read the WG issues list, the WG Last Call issues list, the WG Candidate Recommendation issues list and the WG Proposed Recommendation issues list .

Report

Summary List of Outstanding Issues

idStatusSpecTopicClassReqTitle

Detailed List of Issues

idSpecReqTopicClassStatusRaised ByOwner
1recpart2n/aTypoEditorialClosedTony Graham
Title: Section 7.4 typo
Description:
 The first word in the note in Section 7.4, Supported Features, [1] of
 the "SOAP 1.2. Part 2: Adjuncts" Recommendation should be 'Other', not
 'other'.
[email]
Proposal:
Resolution:
The XMLP WG has decided to accept your proposed resolution issue 1
  
[email]
2recpart1/part2n/aTypoEditorialClosedMark Goodman
Title: Typo in copyright statements
Description:
Both SOAP 1.2 part 1 and part 2 mention viability in the copyright 
statement where I believe liability is meant.
    
[email]
Proposal:
Resolution:
The XMLP WG has decided to change "viability" to "liability" in Parts 1 
and 2 per your suggestion.
  
[email]
3recpart1n/aEditorialClosedNoah Mendelsohn
Title: editorial issue - section 2
Description:
 I just noticed that in Section 2 of the Rec we have a sentence:

 "It is the responsibility of each such features to define any combined
 processing."

 I believe it would be correct to say instead

 "It is the responsibility of each such feature to define any combined
 processing."

 -or if you prefer-

 "It is the responsibility of any such features to define any combined
 processing."
  
[email]
Proposal:
Resolution:
The XMLP WG has decided to accept your "each such feature" correction.
  
[email]
4recpart0n/aEditorialClosedNilo Mitra
Title: missing double quote
Description:
Example 6b of the SOAP 1.2 primer: a double quote is missing in the document
at http://www.w3.org/TR/2003/REC-soap12-part0-20030624/

<pre>
&lt;?xml version='1.0' ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"&gt;
----------------------.............................................^missing double-quote
  
[email]
Proposal:
Resolution:
The XMLP WG has decided to add the missing double quote per your suggestion.
  
[email]
5recpart1/part2n/aEditorialClosedTony Graham
Title: SOAP 1.2 Part 1 and Part 2 references to other parts
Description:
In the SOAP 1.2 Part 1 Recommendation [1], the references to SOAP 1.2
Part 0 and SOAP 1.2 Part 2 are both to "W3C Proposed Recommendation"
even though the dates and the URLs are correct for the Recommendation
versions of the other parts.

In the SOAP 1.2 Part 2 Recommendation [2], the references to SOAP 1.2
Part 0 and SOAP 1.2 Part 1 are both to "W3C Proposed Recommendation"
even though the dates and the URLs are correct for the Recommendation
versions of the other parts.

The SOAP 1.2 Part 0 Recommendation does not have this error.
[email]
Proposal:
Resolution:
The XMLP WG has decided to accept your proposed resolution issue 1, and 
to reference the "Recommendation" rather than the "Proposed Recommendation" for issue 5.
  
[email]
6rectest colln/aClosedChin Chee-Kai
Title: SOAP 1.2 Test collection Errors
Description:
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:T14
> 
> Inside <env:Header>,   <test:echoOk> is incorrectly
> matched with </test:unknown>
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:T20
> 
> This test appears to be missing.  Test:T19 is continued
> with Test:T21
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:T33
> 
> Inside <env:Body> of Node A's message, <test:DoesNotExist>
> is incorrectly matched with </test:doesNotExist>
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:T68
> 
> The description mentioned that Node A's message is 
> semantically equivalent to T1's Node A's message, except
> for white space.  It therefore leads me to wonder if the
> initial XML declaration line:
> 
> <?xml version='1.0' ?>
> 
> is missing.
[email]
Proposal: [email (member only)]
Resolution:
The XMLP WG
agrees with your comments regarding tests T14, T33, and T68, and will make
the appropriate corrections. The XMLP WG decided to retain the existing
numbering scheme (i.e. with a gap at T20) in order to retain stability with
regards links and the numbering of assertions.
  
[email]
7rectest colln/aClosedChin Chee-Kai
Title: SOAP 1.2 Test collection Errors (2)
Description:
(some similar errors have been rearranged)
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:T7 Test:T8
> 
> Node A's Message:
> End tag 'test:echoOk' does not match the start tag 'test:Ignore'.
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:T44
> 
> Node C's Message:
> 
>          <return xsi:type="ns1"SOAPStruct"
>                  xmlns:ns1="http://example.org/ts-tests/xsd">
> 
> has typo double-quote, should probably be:
> 
>          <return xsi:type="ns1:SOAPStruct"
>                  xmlns:ns1="http://example.org/ts-tests/xsd">
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:T57
> 
> Node C's Message:
> The 'return' tag was not closed properly.
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:T58
> 
> Node A's Message:
> End tag 'test:array' does not match the start tag 'inputIntegerArray'.
> 
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:T59
> 
> Node A's Message:
> 
>    <item enc:id="data" xsi:type"xsd:string" enc:ref="#data">hello</item>
> 
> has missing "=", should probably be:
> 
>    <item enc:id="data" xsi:type="xsd:string" enc:ref="#data">hello</item>
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:T64
> 
> Node A's Message:
> 
>       <!NOTATION application_xml SYSTEM
>        'http://www.isi.edu/in-notes/iana/assignments/media-types/application/xml'>
> 
> is declared outside of DTD.  As it is, this forms an XML parsing error,
> not a "DTD not supported by SOAP 1.2" error.
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:T65
> 
> Node A's Message:
> 
>       <!ELEMENT Envelope (Body) >
>       <!ELEMENT Body (echoOk) >
>       <!ELEMENT echoOk (#PCDATA) >
> 
> are declared outside of DTD.  As it is, this forms an XML parsing error,
> not a "DTD not supported by SOAP 1.2" error.
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:T73
> 
> Node C's Message:
> 
>       <return xsi:type="xsd:string">hello world</return>
> 
> references undeclared namespace prefix "xsi".
> 
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:T75
> 
> Node C's Message:
> End tag 'test:resonseResolvedRef' does not match the start
> tag 'test:responseResolvedRef'.
> 
> Note the missing "s" in the end tag.
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:T77
> 
> Node A's Message (3rd):
> The 'inputString' tag isn't closed properly.
> 
> 
> Node C's Message (3rd):
> The 'return' tag isn't closed properly.
> 
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:T80
> 
> Node A's message has undefined namespace for prefix "test".
> Also, the attribute for the <test:echoOk> element should
> be qualified with "env", otherwise Node C should behave
> as if <env:encodingStyle> is absent and not defined with
> an incorrect value.
> 
> Suggest the following replacement:
> 
> <?xml version="1.0"?>
> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
>   <env:Body>
>     <test:echoOk env:encodingStyle="http://example.org/PoisonEncoding"
>                  xmlns:test="http://example.org/ts-tests">
>       foo
>     </test:echoOk>
>   </env:Body>
> </env:Envelope>
> 
> 
> Node C's Message:
> 
>     <env:Value>env:DataEncodingUnknown<env:/value>
> 
> has an incorrect closing tag "<env:/value>".
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:SBR1-echoString (081)
> Test:SBR1-echoInteger (083)
> Test:SBR1-echoVoid (089)
> 
> Node A's Message:             <?xml version="1.0">
> should be closed with "?>".
> 
> Node C's Message:             <?xml version="1.0">
> should be closed with "?>".
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:SBR2-echoSimpleTypesAsStruct     (096)
> Test:XMLP-4 (154)
> 
> Node C's Message:
> 
>       <return xsi:type="ns1"SOAPStruct"
>               xmlns:ns1="http://soapinterop.org/xsd">
> 
> has incorrect double-quotation that should probably
> be a colon ":".
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:SBR2-echoMeStringRequest (100)
> Test:SBR2-echoMeStructRequest (101)
> Test:SBR2-echoMeUnknown (102)
> 
> Node A's Message (1st):               <?xml version="1.0?>
> was not properly closed with a double-quotation mark.
> 
> Node A's Message (2nd):               <?xml version="1.0?>
> was not properly closed with a double-quotation mark.
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:SBR2-echoMeUnknown (102)
> 
> Node A's Message (3rd):               <?xml version="1.0?>
> was not properly closed with a double-quotation mark.
> 
> Node A's Message (4th):               <?xml version="1.0?>
> was not properly closed with a double-quotation mark.
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:XMLP-1 (151)
> 
> Node A's Message (1st):               <?xml version="1.0">
> should be closed with "?>" instead.
> 
> Node C's Message (1st):               <?xml version="1.0">
> should be closed with "?>" instead.
> 
> Node A's Message (2nd):               <?xml version="1.0">
> should be closed with "?>" instead.
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:XMLP-3 (153)
> 
> Node C's Message:
> End tag 'm:getTimeResponse' does not match the
> start tag 'sb:getTimeResponse'.
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:XMLP-5 (155)
> 
> Node A's Message:
> 
>       <env:Body
>        env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/>
> 
> has a missing double-quote after "encoding".
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:XMLP-6 (156)
> Test:XMLP-9 (159)
> 
> Node A's Message:             <?xml version="1.0?>
> was not properly closed with a double-quotation mark.
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:XMLP-9 (159)
> 
> Node C's Message:
> 
>       <env:Value>env:DataEncodingUnknown<env:/value>
> 
> has an incorrect closing tag "<env:/value>".
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:XMLP-11 (161)
> Test:XMLP-12 (162)
> Test:XMLP-19 (169)
> 
> Node A's Message:             <?xml version="1.0">
> should be closed with "?>" instead.
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:XMLP-13 (163)
> Test:XMLP-14 (164)
> Test:XMLP-15 (165)
> Test:XMLP-16 (166)
> Test:XMLP-17 (167)
> Test:XMLP-18 (168)
> 
> Node A's Message:             <?xml version="1.0">
> should be closed with "?>" instead.
> 
> Node C's Message:             <?xml version="1.0">
> should be closed with "?>" instead.
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
[email]
Proposal:
Resolution:
The XMLP WG has decided to close this issues with the resolution
proposed in 
Anish's email
[email
8rectest colln/aClosedChin Chee-Kai
Title: SOAP 1.2 Test collection Errors (3)
Description:
(some similar errors have been rearranged)
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:T44
> Test:SBR2-echoSimpleTypesAsStruct (096)
> Test:XMLP-4 (154)
> 
> Node C's Message:
> 
>       <rpc:result>return<rpc:result>
> 
> The element <rpc:result> is not closed properly.
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:T64
> 
> Node A's Message:
> 
> <!NOTATION application_xml SYSTEM 'http://www.isi.edu/in-notes/iana/assignments/media-types/application/xml' >
> 
> appears to be an improper document declaration.
> 
> Suggest changing to:
> 
> <!DOCTYPE Envelope [
> <!NOTATION application_xml SYSTEM 'http://www.isi.edu/in-notes/iana/assignments/media-types/application/xml' >
> ]>
> 
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:T65
> 
> Node A's Message:
> 
> <!ELEMENT Envelope (Body) >
> <!ELEMENT Body (echoOk) >
> <!ELEMENT echoOk (#PCDATA) >
> 
> appears to be elements of an improper document declaration.
> 
> Suggest changing to:
> 
> <!DOCTYPE Envelope [
> <!ELEMENT Envelope (Body) >
> <!ELEMENT Body (echoOk) >
> <!ELEMENT echoOk (#PCDATA) >
> ]>
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:T73
> 
> Node C's Messages:
> Closing tag "</test:echoString> " should be changd to"</test:echoStringResponse>
> to match the start tag.
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:SBR1-echoString (081)
> Test:XMLP-9 (159)
> Test:XMLP-13 (163) 
> Test:XMLP-14 (164)
> Test:XMLP-15 (165)
> Test:XMLP-16 (166) 
> Test:XMLP-17 (167)
> Test:XMLP-18 (168)
> Test:XMLP-19 (169)
> 
> Node A's Message:
> <inputString> is not closed properly.
>
> + same on Node C's message for (163, 164, 165, 166, 168)
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:SBR1-echoStringArray (082)
> Test:SBR1-echoIntegerArray (084)
> Test:SBR1-echoFloat (085)
> Test:SBR1-echoBase64 (090)
> Test:SBR1-echoDate (091)
> Test:SBR2-echoHexBinary (092)
> Test:SBR2-echoDecimal (093)
> Test:SBR2-echoBoolean (094)
> 
> Node C's Message:
> 
>     <sb:echoStringArrayResponse xmlns:test="http://soapinterop.org/"
> 
> "xmlns:test" should be changed to "xmlns:sb" as sb currently has
> no namespace value defined.
>
> (+ Node A's Message in 090, 091)
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:SBR1-echoInteger (083)
> 
> Node A's Message:
> 
>       <inputInteger xsi:type="xsd:int">123<inputInteger>
> 
> <inputInteger> is not closed properly.
> 
> Node C's Message:
>     </sb:echoString>
> 
> Closing tag should be changed to </sb:echoIntegerResponse> to match
> the start tag.
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:SBR2-echoMeUnknown (102)
> 
> Node A's Messages:
> 
>     </h:echoMeKnown>
> 
> should be changed to </h:echoMeUnknown>.
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:XMLP-5 (155)
> 
> Node A's Message:
> 
>    <env:Body env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/>
> 
> should look like:
> 
>   <env:Body env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding">
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:XMLP-6 (156)
> 
> Node A's Message:
> 
>     </h:echoMeKnown>
> 
> should be changed to     </h:Unknown>.
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:XMLP-11 (161)
> 
> Node A's Message:
> 
>  <inputInteger xsi:type="xsd:int">abc<inputInteger>
> 
> <inputInteger> was not closed properly.
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:XMLP-15 (165)
> Test:XMLP-16 (166) + node C
> 
> Node A's Message:
> 
>     <sb:Unknown soap:role="http://www.w3.org/2003/05/soap-envelope/role/next"
>                 xmlns:sb="http://soapinterop.org/">
> 
> should be:
> 
>     <sb:Unknown env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
>                 xmlns:sb="http://soapinterop.org/">
> 
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:XMLP-18 (168)
> 
> Node A and C's Message:
> 
>     <sb:Unknown
>         soap:role="http://www.w3.org/2003/05/soap-envelope/role/next"
>         soap:relay="true"
>         xmlns:sb="http://soapinterop.org/">
>     </sb:Unknown>
> 
> 
> should be:
> 
>     <sb:Unknown
>         env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
>         env:relay="true"
>         xmlns:sb="http://soapinterop.org/">
>     </sb:Unknown>
> 
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> Test:XMLP-19 (169)
> 
> Node A's Message:
> 
>     <sb:Unknown
>         soap:role="http://www.w3.org/2003/05/soap-envelope/role/next"
>         soap:mustUnderstand="true"
>         xmlns:sb="http://soapinterop.org/">
> 
> should be:
> 
>     <sb:Unknown
>         env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
>         env:mustUnderstand="true"
>         xmlns:sb="http://soapinterop.org/">
> 
  
[email]
Proposal: [email]
Resolution:
You raised an issue (recorded as issue 8rec) against the SOAP 
Version 1.2 Specification Assertions and Test Collection document. 
The XMLP WG resolved this issue by accepting the proposed resolution in [email].
  
9recpart1n/aClosedDaniel Barclay
Title: feedback - Table 3 almost inpenetrable
Description:
Regarding the SOAP 1.2 Part 1 specification at
http://www.w3.org/TR/2003/REC-soap12-part1-20030624:

Table 3 is confusing and hard to understand.

(Try to pretend you (readers of this comment) don't already know SOAP,
and then try to interpret the table.)

The "Assumed" column is ambiguous, seeming to refer to assuming in the
sense of assuminng to be the case (as opposed to the apparently intended
meaning of assuming in the sense of taking on a role).

Additionally, at least with the current column labeling, it isn't clear
whether the "Assumed" column is an "output" (a function of earlier
columns) or is an "input."  (Yes, one can eventually figure it out, but
it can take a while.)

The paragraph mentioning the table should specify briefly (a sentence
or so) the relationship between the cells in a row.

Perhaps something _very_ roughly like:

  For each type of role, the table shows whether a node can or can't
  assume that type of role, and, for each possible case, whether
  header blocks are processed and whether they are forwarded.
  would work.
  
[email]
Proposal:
Resolution:
At its recent f2f, the XMLP WG decided to close this issue by adding the 
following caption to Table 3.

<caption>
Table 3 summarizes the forwarding behavior of a SOAP node for a given 
header block. Each row contains a different combination of the value of 
the header block's role attribute information item, whether the SOAP 
node is acting in that role and whether the header block has been 
understood and processed, and shows whether the header block will be 
forwarded or removed.
</caption>

[email]
10recpart1n/aClosedDaniel Barclay
Title: feedback - wording (semantic and editorial)
Description:
Some feedback regarding SOAP Version 1.2 Part 1: Messaging Framework
(24 June 2003):

Wording related to semantics:

* Section 2.7.2.1 says:

     ...
     Element information items for additional header blocks MAY be added to
     the [children] property of the SOAP Header element information item as
     detailed in 2.7.2 SOAP Forwarding Intermediaries.

     In this case, a SOAP Header element information item MAY be added, as
     the first member of the [children] property of the SOAP Envelope element
     information item, if it is NOT already present."
     ...

   The wording of the second paragraph doesn't quite allow for multiple
   header elements: can't all be the first child of the parent element.

* Section 5.1.1 says:

     ...
     The scope of the encodingStyle attribute information item is that of its
     owner element information item and that element information item's
     descendants, unless a descendant itself carries such an attribute
     information item.
     ...

   The wording seems to have several problems.

   1.  Is the scope of an attribute the _scope_ of some elements or is it
       the elements?

       (If the scope of the attribute is the scope of some elements, then
       what is the scope of an element?  Specifically, does it include its
       descendants?  If so, then the wording "and that element information
       item's descendants" would be redundant, right?)

       Should "the scope...is that of...element" be "the scope...is...
       element"?

    2. The wording that tries to exclude descendents that have their own
       encodingStyle attributes doesn't specify what it intends to.

       As written with "unless," the specification says that _any_
       descendent that also carries the attribute excludes _all_
       descendents from the scope (not just those descendents in the
       subtree rooted at the descendent with the attribute).

       (Additionally, nothing clearly limits the scope of the "unless" to
       the phrase "that element information item's descendants," so it can
       also be taken to mean the any descendant with the attribute also
       removes the parent element from the scope.)

       Starting with "except for descendants that..." would more likely
       result in the intended semantics.

* Section 3.3, item 5 says:

     ...we can imagine a module which encrypts and removes the SOAP body,
     inserting instead a SOAP header block containing a checksum and an
     indication of the encryption mechanism used. The specification for such a
     module would indicate that the decryption algorithm on the receiving side
     is to be run prior to any other modules which rely on the contents of the
     SOAP body.

   That seems to refer to removing the plaintext body and adding a header
   that contains only the checksum and algorithm indication (without either
   putting the encrypted body in the header, or added a replacement body
   element with the encrypted data in it).

* Sections 5.4.7.3 and 5.4.8.2 give conflicting definitions of "the qname
   attribute information item."

   The first should limit itself to "the qname attribute information item
   of a SupportedEnvelope element [info. item]" and the other should address
   only NotUnderstood elements.

* "To SOAP, a URI is simply a formatted string that identifies a web resource
   via its name, location, or any other characteristics."

   Should that include "location, or any other characteristics" after "name"?
   Saying that URIs identify things by location can imply that one must
   resolve host names (e.g., abc.com vs. www.abc.com) to determine identity.

   Don't other W3C specifications (especially XML Namespaces) treat URIs just
   as strings?

Just editorial:

* The wording "an ordered list...of names...in the order most to least
   preferred" is unclear, not quite grammatical, and possibly redundant.

   The phrase "...in the order most to least preferred" isn't grammatical,
   and suggests "in the _order_ most preferred" by the node, instead of
   ordered from the _version_ most preferred by the node.

   Maybe it should say "...a list...of names...ordered from most preferred to
   least preferred."

* "...character information item children whose character code is amongst
   the white space characters..." should probably be "...character information
   item children whose character codes are amongst the white space
   characters..." (several occurrences).

* Properties are referred to with brackets, as in "the [children]
   property."

   That is not the standard English use of brackets, and is confusing.
   (Try reading "The [notations] and [unparsed entities] properties are
   both empty. The [base URI], [character encoding scheme] and [version]
   properties can have any legal value.")

   Why not write "the children property" or:

     the "children" property

* "The semantics of one or more SOAP header blocks in a SOAP message, or
   the SOAP MEP used MAY require..."

   Unbalanced comma; should be:

    "The semantics of one or more SOAP header blocks in a SOAP message, or
     the SOAP MEP used, MAY require..."

* "SOAP senders SHOULD NOT generate, but SOAP receivers MUST accept the
   SOAP role..."

   Unbalanced comma; should be:

   "SOAP senders SHOULD NOT generate, but SOAP receivers MUST accept, the
   SOAP role..."

* Section 3.1 says:

     ...example features may include "reliability", "security", "correlation",
     "routing", and message exchange patterns (MEPs)
     ...

   The words appear to be used in their normal senses, but they are enclosed
   in quotes.  Either the quotes should be removed, or something should be
   changed to make clear why they are in quotes.  (Are the words quoted
   because they are literal names for the features?  If so, their being
   names should be mentioned.)

* "e.g. ..." should be "e.g., ..." (at least one occurrence)

* "i.e. ..." should be "i.e., ..." (at least one occurrence)

* "...items...SHOULD have..., that is the name of the element SHOULD..."
   should be:

     ...items...SHOULD have...; that is, the name of the element SHOULD..."

   (There are several instances of that.)

* "namespace qualified" should be "namespace-qualified" (at least two
   occurrences); also:

   - "human readable explanation" should be "human-readable explanation"
   - "SOAP related security problems" should be "SOAP-related security
     problems"
   - "SOAP based authentication mechanism" should be "SOAP-based
     authentication mechanism"

* In:

     SOAP intermediaries are by definition men-in-the-middle, and represent
     an opportunity for man-in-the-middle attacks.

   the occurrence of "men-in-the-middle" should probably be "men in the
   middle" because in the above sentence it is not being used as an
   adjective and therefore doesn't need to be bundled together (as
   "man-in-the-middle" is used and bundled at the end of the sentence).
  
[email]
Proposal: [email]
Resolution:
------------------------------

***********************
* Section 2.7.2.1 says:

      ...
      Element information items for additional header blocks MAY be added to
      the [children] property of the SOAP Header element information item as
      detailed in 2.7.2 SOAP Forwarding Intermediaries.

      In this case, a SOAP Header element information item MAY be added, as
      the first member of the [children] property of the SOAP Envelope 
element
      information item, if it is NOT already present."
      ...

    The wording of the second paragraph doesn't quite allow for multiple
    header elements: can't all be the first child of the parent element.

Proposed resolution:
--------------------
*No* change.

Rationale:
SOAP Header eii and SOAP Header block eii must not be mixed-up.
The SOAP Envelope eii may contain at most one SOAP Header eii in its 
children. The SOAP Header eii may contain zero or more SOAP header block 
eii in its children.
If an intermediary wishes to add a Header block eii in a SOAP message 
not containing any Header block eii, this intermediary must add a SOAP 
Header eii in the SOAP Envelope eii to contain the new Header block eii. 
This SOAP Header eii will be the first child of the SOAP Envelope eii.
Therefore, the above mentionned second paragraph is correct.

***********************
* Section 5.1.1 says:

      ...
      The scope of the encodingStyle attribute information item is that 
of its
      owner element information item and that element information item's
      descendants, unless a descendant itself carries such an attribute
      information item.
      ...

    The wording seems to have several problems.

    1.  Is the scope of an attribute the _scope_ of some elements or is it
        the elements?

        (If the scope of the attribute is the scope of some elements, then
        what is the scope of an element?  Specifically, does it include its
        descendants?  If so, then the wording "and that element information
        item's descendants" would be redundant, right?)

        Should "the scope...is that of...element" be "the scope...is...
        element"?

     2. The wording that tries to exclude descendents that have their own
        encodingStyle attributes doesn't specify what it intends to.

        As written with "unless," the specification says that _any_
        descendent that also carries the attribute excludes _all_
        descendents from the scope (not just those descendents in the
        subtree rooted at the descendent with the attribute).

        (Additionally, nothing clearly limits the scope of the "unless" to
        the phrase "that element information item's descendants," so it can
        also be taken to mean the any descendant with the attribute also
        removes the parent element from the scope.)

        Starting with "except for descendants that..." would more likely
        result in the intended semantics.

Proposed resolution:
--------------------
Reword the paragraph similar to namespace 1.1 scope definition :
<proposal>
The scope of the encodingStyle attribute information item is its [owner 
element] and that element information item's descendants, excluding the scope
of any inner encodingStyle attribute information item.
</proposal>
The nature of the change is an editorial correction that does not affect 
conformance.

Rationale:
As the scoping of the encodingStyle aii is similar to the scoping of 
namespace declaration, it is expected that the current definition, 
althought lacking some clarity is well understood by readers.
However, some rewording may prevent any confusion.

***********************
* Section 3.3, item 5 says:

      ...we can imagine a module which encrypts and removes the SOAP body,
      inserting instead a SOAP header block containing a checksum and an
      indication of the encryption mechanism used. The specification for 
such a
      module would indicate that the decryption algorithm on the 
receiving side
      is to be run prior to any other modules which rely on the contents 
of the
      SOAP body.

    That seems to refer to removing the plaintext body and adding a header
    that contains only the checksum and algorithm indication (without either
    putting the encrypted body in the header, or added a replacement body
    element with the encrypted data in it).

Proposed resolution:
--------------------
Do *no* change.

Rationale:
The exerpt perhaps lacks some clarity, however it is only an example and 
as such is sufficient for providing some concrete application of item 5 
requirements.

***********************
* Sections 5.4.7.3 and 5.4.8.2 give conflicting definitions of "the qname
    attribute information item."

    The first should limit itself to "the qname attribute information item
    of a SupportedEnvelope element [info. item]" and the other should 
address
    only NotUnderstood elements.

Proposed resolution:
--------------------
Do *no* change.

Rationale:
Taken in context, it is clear that the qname aii defined in 5.4.7.3 
applies to the SupportedEnvelope element and that the qname aii defined 
in 5.4.8.2 applies to the NotUnderstood element.

***********************
* "To SOAP, a URI is simply a formatted string that identifies a web 
resource
    via its name, location, or any other characteristics."
(Ed note: Section 6, first paragraph)

    Should that include "location, or any other characteristics" after 
"name"?
    Saying that URIs identify things by location can imply that one must
    resolve host names (e.g., abc.com vs. www.abc.com) to determine 
identity.

    Don't other W3C specifications (especially XML Namespaces) treat 
URIs just
    as strings?

Proposed resolution:
--------------------
Change the sentence by removing everything after "via":

To SOAP, a URI is simply a formatted string that identifies a web resource.


Rationale:
The sentence cited by commentator summaries the first paragraph of 
Section 1.2 of RFC 2396 (which defines URIs) and is therefore correct.

However, in order not to mislead readers, it has been choosen to remove examples
of how a URI identifies a web resource.

***********************
* The wording "an ordered list...of names...in the order most to least
    preferred" is unclear, not quite grammatical, and possibly redundant.
(Ed note: Section 5.4.7.1, paragraph 1)

    The phrase "...in the order most to least preferred" isn't grammatical,
    and suggests "in the _order_ most preferred" by the node, instead of
    ordered from the _version_ most preferred by the node.

    Maybe it should say "...a list...of names...ordered from most 
preferred to
    least preferred."

Proposed resolution:
--------------------
Do *no* change.

Rationale:
The sentence althought somewhat long is understandable as is.

***********************
* "...character information item children whose character code is amongst
    the white space characters..." should probably be "...character 
information
    item children whose character codes are amongst the white space
    characters..." (several occurrences).

Proposed resolution:
--------------------
Split the sentence in two in each appropriate places:
<proposal>
.. character information item children. The character code of each such
character information item MUST be amongst the white space characters as
defined by XML 1.0 [XML 1.0].
</proposal>

Rationale:
As both sentences could be correct depending on the point of view, the
solutions choosen is to remove the problem and make the whole sentence easier
to read by splitting it in two.

***********************
* Properties are referred to with brackets, as in "the [children]
    property."

    That is not the standard English use of brackets, and is confusing.
    (Try reading "The [notations] and [unparsed entities] properties are
    both empty. The [base URI], [character encoding scheme] and [version]
    properties can have any legal value.")

    Why not write "the children property" or:

      the "children" property

Proposed resolution:
--------------------
Do *no* change.

Rationale:
The square brackets notation for property names is the standard notation 
defined by the XML Infoset specification (see XML Infoset, Section 1, 
paragraph 5).

***********************
* "The semantics of one or more SOAP header blocks in a SOAP message, or
    the SOAP MEP used MAY require..."
(Ed note: section 2.7.2, paragraph 1)

    Unbalanced comma; should be:

     "The semantics of one or more SOAP header blocks in a SOAP message, or
      the SOAP MEP used, MAY require..."

Proposed resolution:
--------------------
*Accept* proposal.
The nature of the change is an editorial correction that does not affect 
conformance.

Rationale:
There is effectively a missing comma.

***********************
* "SOAP senders SHOULD NOT generate, but SOAP receivers MUST accept the
    SOAP role..."
(Ed note: section 5.3.2, paragraph 8)

    Unbalanced comma; should be:

    "SOAP senders SHOULD NOT generate, but SOAP receivers MUST accept, the
    SOAP role..."

Proposed resolution:
--------------------
*Accept* proposal.
The nature of the change is an editorial correction that does not affect 
conformance.

Rationale:
There is effectively a missing comma.

***********************
* Section 3.1 says:

      ...example features may include "reliability", "security", 
"correlation",
      "routing", and message exchange patterns (MEPs)
      ...

    The words appear to be used in their normal senses, but they are 
enclosed
    in quotes.  Either the quotes should be removed, or something should be
    changed to make clear why they are in quotes.  (Are the words quoted
    because they are literal names for the features?  If so, their being
    names should be mentioned.)

Proposed resolution:
--------------------
Do *no* change.

Rationale:
The words are used to indicate some generic kind of functionnality. They 
could have been written without the quotes, but as this does not hinder 
the understanding of the sentence, there is no need to remove the quotes 
or change the sentence.

***********************
* "e.g. ..." should be "e.g., ..." (at least one occurrence)

Proposed resolution:
--------------------
Add a comma after each occurrence of "e.g.".
The nature of the change is an editorial correction that does not affect 
conformance.
(Ed note: there are several occurrences).

***********************
* "i.e. ..." should be "i.e., ..." (at least one occurrence)

Proposed resolution:
--------------------
Add a comma after each occurrence of "i.e.".
(Ed note: Section 2.4, paragraph 1, Section 4.2, paragraph 4).

***********************
* "...items...SHOULD have..., that is the name of the element SHOULD..."
    should be:

      ...items...SHOULD have...; that is, the name of the element SHOULD..."

    (There are several instances of that.)

Proposed resolution:
--------------------
Accept proposed change.
The nature of the change is an editorial correction that does not affect 
conformance.
(Ed note: Section 5.2.1, First bullet; Section 5.3.1, First bullet; 
Sectino 5.4.5.1, First bullet).

***********************
* "namespace qualified" should be "namespace-qualified" (at least two
    occurrences); also:

Proposed resolution:
--------------------
Accept proposed change.
The nature of the change is an editorial correction that does not affect 
conformance.
(Ed note: many occurrences).

***********************
    - "human readable explanation" should be "human-readable explanation"

Proposed resolution:
--------------------
Accept proposed change.
The nature of the change is an editorial correction that does not affect 
conformance.
(Ed note: Section 5.4.2, paragraph 1; Section 5.4.2.1, paragraph 1).

***********************
    - "SOAP related security problems" should be "SOAP-related security
      problems"

Proposed resolution:
--------------------
Accept proposed change.
The nature of the change is an editorial correction that does not affect 
conformance.
(Ed note: Section 7.2, paragraph 2).

***********************
    - "SOAP based authentication mechanism" should be "SOAP-based
      authentication mechanism"

Proposed resolution:
--------------------
Accept proposed change.
The nature of the change is an editorial correction that does not affect 
conformance.
(Ed note: Section 7.3, paragraph 3).

***********************
* In:
      SOAP intermediaries are by definition men-in-the-middle, and represent
      an opportunity for man-in-the-middle attacks.
(Ed note: Section 7.2, paragraph 1).

    the occurrence of "men-in-the-middle" should probably be "men in the
    middle" because in the above sentence it is not being used as an
    adjective and therefore doesn't need to be bundled together (as
    "man-in-the-middle" is used and bundled at the end of the sentence).

Proposed resolution:
--------------------
Accept proposed change.
The nature of the change is an editorial correction that does not affect 
conformance.
  
[email]
11recpart2n/aClosedDaniel Barclay
Title: feedback - wording (semantic and editorial)
Description:
Some feedback regarding SOAP Version 1.2 Part 2:

Wording related to semantics:

* Section 3.1.6 doesn't say in which order array dimension sizes are listed.
   (It doesn't say whether the first size in the list is the size of the first
   dimension or is the size of the last dimension.)

* Section 3.1.6 uses its own definition of whitespace.  Should it refer to
   the XML specification's definition, so that if the XML specification's
   definition is modified in some future version (for example to include
   the EBCDIC newline character), future versions of the SOAP spec (which
   would refer to XML x.x instead of XML 1.0) will automatically follow XML
   evolution?

* Section 3.1.6 doesn't define that sequences of digit characters allowed
   by the syntax are to be interpreted as regular decimal representations
   of integers.

* "A relative URI whose base URI is ..."

   Is that wording technically correct?

   Does a relative URI really have a base URI, or is it the occurrence of
   a relative URI that has a base URI?

   (The relative URI "x" doesn't have a base URI.  If I put it (a copy of
   it?) in an HTML document and viewed the document, then the occurrence in
   the document would have a base URI (the URI from which I retrieved the
   document).)

   RFC 2396 refers to the base URI of a document and defines the base URI
   for resolution, but doesn't seem to mention a base URI of a URI reference.

   Should "A relative URI whose base URI is..." be "A relative URI that will
   be resolved against..."?

   Also, must it be relative, or is it just allowed to be relative?

Just editorial:

* The wording "invocations of method and procedure calls" is confusingly
   inaccurate.  (A call _is_ an invocation.  You can invoke a procedure;
   you can't invoke a procedure _call_ (well, unless you're talking about
   "invoking" (executing) a procedure call statement that sets up for and
   then actually invokes a procedure).)

* "is entirely platform independent" should be "is entirely
    platform-independent "

* As written, the wording:

     When mapping to or from a programming language method or procedure
     call, the name of which identifies...

   refers to the (non-existent) name of a _call_, instead of to the called
   method or procedure.

* "on an application or procedure-specific basis" should be
   "on an application- or procedure-specific basis"

* "the binding specific expression" should be "the binding-specific
    expression"

* "application defined data" should be "application-defined data"

* "the application defined name" should be "the application-defined name"

* "i.e. ..." should be "i.e., ..." (several instances)

* Delimiting special terms with brackets (e.g., "A [local name] of ref")
   is confusing (because it is not standard English use of brackets).

* "The struct is named identically to the procedure or method name":

   Either:

     "The struct name is identical to the procedure or method name."

   or:

     "The struct is named identically to the procedure or method."

* "are implementation defined" should be "are implementation-defined"

* "the distinction between per message-exchange and more widely scoped
   properties":

   - "per message-exchange [properties]" should be "per-message-exchange
     [properties]"

   - "the distinction between per-message-exchange properties and more
     widely scoped properties"  would be clearer

* "containers called Message Exchange Context..."

   Shouldn't that be "containers called the Message Exchange Context..."?

* In Figure 1, at least three labels don't match the terms in the
   immediately preceding text:
   - "SOAP" (instead of "SOAP node")
   - "Environment" (instead of Environment Context)
   - "Transport Message Exchange Context" (instead of "Message Exchange
     Context")

* It looks like "Environment" was intended to be renamed to "environment
   context" but not all references were edited.  For example, section
   5.1.2.2 says:

      The environment context is...

      The values...in Environment...

   and section 5.1.2 says:

      called...Environment Context.

   The intended form should be determined and all references should be
   edited to follow that indented form.

* Table 4 is extremely wide (and can be hard to read and print).  It
   would be helpfule if optional line breaks were be inserted in the
   long URIs in that table (and in other tables).

* "SOAP places no restrictions on the specificity of the URI or that it
   is resolvable."

   Something didn't get edited consistently.

* "The media type of the request entity body (if present) otherwise,
   omitted..."

   apparently should be:

     The media type of the request entity body, if present; otherwise,
     none...

* "The response message follows in HTTP response..." should be
   "The response message follows in the HTTP response..."

* "it is recommended that such behavior is disabled" should be
   "it is recommended that such behavior be disabled"

* "...it is strongly RECOMMENDED that...implications...is fully understood"
   should be:

      ...it is strongly RECOMMENDED that...implications...be fully understood

* "the schema recommendation is build on..." should be "the schema
   recommendation is built on..."

* The SOAP encoding schema linked to from the main document says:

   Schema defined in the SOAP Version 1.2 Part 2 specification Proposed
     Recommendation:
      http://www.w3.org/TR/2003/PR-soap12-part2-20030507/

* The main document _contain_ a copy of the SOAP Encoding Schema in the
   text.  Doing so would make the HTML document more self-contained.
  
[email]
Proposal: [email]
Resolution:
[..]
RESOLUTION: The Working Group has split this into another issue for 
separate consideration.
[..]
RESOLUTION: The Working Group has an open issue regarding XML 1.1, and 
will consider this as part of it.
[..]
RESOLUTION: No change. By default, all digits are to be interpreted in 
this fashion. This is accepted practice in W3C specifications.
[..]
RESOLUTION: adopt suggested text. (table 4)
[..]
RESOLUTION: change "invocations of method and procedure calls" (section 
4 Intro) to "invocations of methods and procedures."
[..]
RESOLUTION: change "language method or procedure call" (4.1.1) to 
"language method or procedure."
[..]
RESOLUTION: Adopt the suggested text.
[..]
RESOLUTION: Normalise on the form with a comma.
[..]
RESOLUTION: No change. This is well-recognised notation in W3C 
specifications.
[..]
RESOLUTION: Adopt the second suggestion. (4.2.1)
[..]
RESOLUTION: Adopt the second suggestion. (5.1.2)
[..]
RESOLUTION: No change.
[..]
RESOLUTION: Update the illustration. (5.1.2)
[..]
RESOLUTION: normalise on "Environment Context."
[..]
RESOLUTION: Future editorial work will adjust table presentation.
[..]
RESOLUTION: "SOAP places no restrictions on the specificity of the URI,
and does not guarantee that it is resolvable."
[..]
RESOLUTION: Adopt the suggested text. (Table 16)
[..]
RESOLUTION: Adopt the suggested text. (Table 17)
[..]
RESOLUTION: Adopt the suggested text. (7.5.1.2)
[..]
RESOLUTION: Adopt the suggested text. (A.2)
[..]
RESOLUTION: Adopt the suggested text. (C.1) Also, should be 
"Recommendation", not "recommendation", throughout, with full document 
name on first instance.
[..]
RESOLUTION: Update text and link to REC. (8.1, 8.2)
[..]
RESOLUTION: No change. XML Schemas are not intended to be 
human-readable.
  
[email]
12recpart1n/aEditorialClosedMarc Hadley
Title: Diff ma rkup in SOAP 1.2 REC
Description:
I spotted some diff markup in section 2.7.2.1[1] of SOAP 1.2 part 1. 
The second paragraph of bullet 3 is highlighted in green.

I propose that the diff markup (and hence the green background) be 
removed in a subsequent revision.
  
[email]
Proposal:
Resolution:
Remove the diff markup as suggested.
  
email
13recpart0-1n/aClosedYuxiao Zhao
Title: comments on SOAP 1.2 03-06-24
Description:
I don't know if other people have mentioned these things:

1. Example 5 in SOAP 1.2 part 1:
xmlns:ns2="http://schemas.xmlsoap.org/soap/envelope/" should be no last "/".

2. In 2.1, SOAP 1.2 part 0:
"The choice of what data is placed in a header block and what goes in the SOAP 
body are decisions taken at the time of application design."
 It may be better to change "choice" into "choices" and "taken" into "made".
  
  3. In 2.2.1, SOAP1.2 part 0:
  "The message exchange in Examples 1 and 2 are cases where XML-based content 
  conforming to some application-defined schema are exchanged via SOAP messages."
   It may be better to change "exchange" into exchanges" and "content" into 
   "contents".
    
    4. I wonder if the specifications should conventionally keep unity in using " 
    and ' in one example and/or all examples, for instance, 
    - in part 0, example 7 uses "<?xml version="1.0">" while other examples use 
    "<?xml version='1.0'>"
    - in part 0, example 6a uses "" for xmlns:env but '' for xmlns:rpc.
    - in part 1, examples 6 & 7 use "" for xml version but '' for others.
  
[email]
Proposal: email
Resolution:
1. In response, it is proposed to *not* make this change because the stated
URI is correct (see http://schemas.xmlsoap.org/soap/envelope/).
2. In response, it is proposed to accept the submitters suggestion. The nature
of the change is an editorial correction that does not affect conformance.
3. In response, it is proposed to accept the submitter's suggestion. The
nature of the change is an editorial correction that does not affect
conformance.
4. In response it is proposed to make *no* changes because (a) both forms are
legitimate, and (b) the time and effort required from both editors and
readers is burdensome.
  
email
14recpart2n/aEditorialClosedDavid Booth
Title: Part2 editorial suggestion regarding MEP definitions
Description:
In part2 (http://www.w3.org/TR/2003/REC-soap12-part2-20030624/) Table 4, in 
the "Role" row the "Notes" column states:

[[
A relative URI whose base URI is the value of 
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName
]]

This could be construed as saying that the base URI is the literal 
"http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName". 


For greater clarity, I suggest rewriting the table to indicate the literal 
URI that is to be used for the base URI, such as:

[[
A relative URI whose base URI is 
"http://www.w3.org/2003/05/soap/mep/request-response/"
]]

The same suggestion also applies to table 5.
  
[email]
Proposal: email
Resolution:
To provide further clarification, the proposed resolution is to modify the
"Notes" column for these entries in tables 4 and 5 to read:

A relative URI whose base URI is the value of the Property named
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName
  
[email]
15recspecn/aClosedKieran Dolan
Title: use of xml:lang in the SOAP schema
Description:
The current SOAP schema specification uses the statement 
   <xs:import namespace="http://www.w3.org/XML/1998/namespace">

   rather than the form

   <xs:import namespace="http://www.w3.org/XML/1998/namespace"
     schemaLocation="http://www.w3.org/2001/xml.xsd">

This means that parsers which do not have built-in knowledge of the xml
namespace schema location will fail to parse a SOAP 1.2 schema. I have seen
this problem on both xerces 2.5.0 and on XMLSpy 4.4.

Are there any plans to fix this issue ? It is a real problem for anyone
using validating parsers.
    
[email]
Proposal: email
Resolution:
The XMLP WG has decided to close this issues by accepting the 
suggested change. 
  
[email]
16recspec/rpc scheman/aClosedJacek Kopecky
Title: schema for RPC makes "result" element untyped
Description:
The schema at http://www.w3.org/2003/05/soap-rpc doesn't declare the
type of the element 'result'. I believe the type should be xs:QName, as
per section 4.2.2 of part 2 [1].
[email]
Proposal: email]
Resolution:
Line 22 of the schema [3] is changed:

 <xs:element name='result' />
  to
 <xs:element name='result' type='xs:QName'/>
  
[email]
17recspecn/aClosedDavid Fallside
Title: Bad link in specs
Description:
The references to SOAP 1.1 in the various SOAP 1.2 documents need to be
fixed.
[email]
Proposal:
Resolution:
===================================================
Changes to SOAP 1.2 Rec documents

-- In Part 1, section 8.2, under [SOAP 1.1]
change
(See http://www.w3.org/TR/SOAP/.)
to
(See http://www.w3.org/TR/2000/NOTE-SOAP-20000508/.)
and make the corresponding change to the hyperlink target

-- In Part 0, section 1.1, in description of Section 6
change hyperlink target on the text
SOAP Version 1.1
from
http://www.w3.org/TR/SOAP/
to
http://www.w3.org/TR/2000/NOTE-SOAP-20000508/


-- In Part 0, section 7, under [SOAP 1.1]
change hyperlink target on the text
Simple Object Access Protocol (SOAP) 1.1
from
http://www.w3.org/TR/SOAP/
to
http://www.w3.org/TR/2000/NOTE-SOAP-20000508/


-- In Part 0, section 7, under [SOAP 1.1]
change
(See http://www.w3.org/TR/SOAP/)
to
(See http://www.w3.org/TR/2000/NOTE-SOAP-20000508/)
and make the corresponding change to the hyperlink target


-- In Test Collection, under assertion "Assertion x1-version-soap11",
remove the hyperlink associated with "[soap11]" that appears as text quoted
from the specification.

===================================================

Proposed change to Status section of Rec docs (Parts 1 and 2 only).

Status of this Document
This section describes the status of this document at the time of its
publication. Other documents may supersede this document. The latest
status of this document series is maintained at the W3C.

This document is a Recommendation of the W3C. This document has been
produced by the XML Protocol Working Group, which is part of the Web
Services Activity. It has been reviewed by W3C Members and other
interested parties, and has been endorsed by the Director as a W3C
Recommendation. It is a stable document and may be used as reference
material or cited as a normative reference from another document. W3C's
role in making the Recommendation is to draw attention to the
specification and to promote its widespread deployment. This enhances the
functionality and interoperability of the Web.

<new>SOAP Version 1.2 supercedes all previous versions of SOAP, including
SOAP Version 1.1 [SOAP 1.1].</new>

Comments on this document are welcome. Please send them to the public
mailing-list xmlp-comments@w3.org (archive). It is inappropriate to send
discussion email to this address.
[...]
  
[email]
18recspec/schemasn/aClosedDavid Fallside
Title: Editorial comments on 1.2 specs
Description:
==============================
In http://www.w3.org/2003/05/soap-envelope/

-- Change:

Schema defined in the SOAP Version 1.2 Part 1 specification
     Proposed Recommendation: 
     http://www.w3.org/TR/2003/PR-soap12-part1-20030507/ 
     $Id: xmlp-rec-issues.html,v 1.61 2007/06/20 19:29:10 ylafon Exp $

to:

Schema defined in the SOAP Version 1.2 Part 1 Recommendation:
    http://www.w3.org/TR/2003/REC-soap12-part1-20030624/

-- Change:

'encodingStyle' indicates any canonicalization conventions 
    followed in the contents of the containing element.  For example, the
    value 'http://www.w3.org/2003/05/soap-encoding' indicates the pattern
    described in the last call working draft of SOAP Version 1.2 Part 2:
    Adjuncts

to:

'encodingStyle' indicates any canonicalization conventions
  followed in the contents of the containing element.  For example, the
  value 'http://www.w3.org/2003/05/soap-encoding' indicates the pattern
  described in the SOAP Version 1.2 Part 2 Recommendation at
  http://www.w3.org/TR/2003/REC-soap12-part2-20030624/

-- Change:

<!--  Global element and associated types for managing version transition
as described in Appendix A of the SOAP Version 1.2 Part 1 Last Call Working
Draft

to:

<!--  Global element and associated types for managing version transition
as described in Appendix A of the SOAP Version 1.2 Part 1 Recommendation at
http://www.w3.org/TR/2003/REC-soap12-part1-20030624/

===============================
in http://www.w3.org/2003/05/soap-encoding

-- Change:

 Schema defined in the SOAP Version 1.2 Part 2 specification
      Proposed Recommendation: 
      http://www.w3.org/TR/2003/PR-soap12-part2-20030507/ 
      $Id: xmlp-rec-issues.html,v 1.61 2007/06/20 19:29:10 ylafon Exp $

to:

 Schema defined in the SOAP Version 1.2 Part 2 specification
     Recommendation at http://www.w3.org/TR/2003/REC-soap12-part2-20030624/

===============================
in http://www.w3.org/2003/05/soap-rpc

-- Change:

 Schema defined in the SOAP Version 1.2 Part 2 specification
      Proposed Recommendation: 
      http://www.w3.org/TR/2003/PR-soap12-part2-20030507/
      $Id: xmlp-rec-issues.html,v 1.61 2007/06/20 19:29:10 ylafon Exp $

to:

 Schema defined in the SOAP Version 1.2 Part 2 specification
      Recommendation at http://www.w3.org/TR/2003/REC-soap12-part2-20030624/

===============================
In http://www.w3.org/TR/2003/REC-soap12-testcollection-20030624/#SOAP-PART1

-- Change:

W3C Working Draft "SOAP Version 1.2 Part 1: Messaging Framework"

to:

W3C Recommendation "SOAP Version 1.2 Part 1: Messaging Framework"

===============================
In http://www.w3.org/TR/2003/REC-soap12-testcollection-20030624/#SOAP-PART2

-- Change:

W3C Working Draft "SOAP Version 1.2 Part 2: Adjuncts"

to:

W3C Recommendation "SOAP Version 1.2 Part 2: Adjuncts"
[email]
Proposal:
Resolution:
he XML Protocol WG decided to close issue Rec18 
by accepting the changes proposed by the originator.
  
[email]
19rectest colln/aClosedChin Chee-Kai
Title: SOAP 1.2 Test collection Errors (4)
Description:
Test:T27
Note that Node C's fault message says that the array is declared 
as array of integers, but Node A's message is "echoStringArray"
and the enc:itemType attribute is "xs:string".  The entire test
should be changed from "echoStringArray" to "echoIntegerArray",
and enc:itemType changed to "xs:int" instead.

The Description and Node A's message then become:

+.+.+.+.+.+.+.+.+.+.+.+.+.+.
Description:
Node A sends to node C message with test:echoIntegerArray that has 
encodingStyle attribute with a value of 
"http://www.w3.org/2003/05/soap-encoding", contains an element with 
attribute enc:itemType="xsd:int" (array of integer), but with the 
child element of a complex type. Node C returns a Fault indicating 
that message didn't follow SOAP encoding rules (encoded array content 
didn't correspond to the type declared in the enc:itemType).

Node A's Message:
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
  xmlns:xs="http://www.w3.org/2001/XMLSchema">
<env:Body>
  <test:echoIntegerArray xmlns:test="http://example.org/ts-tests"
   xmlns:enc="http://www.w3.org/2003/05/soap-encoding"
   env:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
   <test:array enc:itemType="xs:int" enc:arraySize="1">
     <a>
        <b>1</b>
     </a>
   </test:array>
  </test:echoIntegerArray>
</env:Body>
</env:Envelope>
+.+.+.+.+.+.+.+.+.+.+.+.+.+.
---------------------

Test:T33
Node C's response message does not contain RPC namespace
definition.

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Body>

should be 

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
  xmlns:rpc="http://www.w3.org/2003/05/soap-rpc">
  <env:Body>
---------------------

Test:T61
The description:
"Node A sends to Node C a message specifying an array with
bound specified by an asterisk. Node C responds with the
count of items that appeared in the input array."

should be:

"Node A sends to Node C a message specifying an array with
bound specified by a mixed use of integer and an asterisk.
Node C responds with a fault stating such use of asterisk
is invalid."
---------------------

Test:T63
The description does not indicate what the server should return
if the client sends a proper 2-character content string.
Thus, the description is not complete.
Client must send a non-2-character content string in order to
pass the test.

As the semantics of the test is really to test the length of string,
the test name should be more properly labeled as

<test:validateStringLength>

instead of

<test:validateCountryCode>

Assuming the semantics of the current description, a 2-character
country code of "XX", for example, would pass the test, but yet 
represents an invalid country code in real life.

---------------------

Test:T66
Description says:
"Node A sends a message to node C with non-empty [encoding]
property. Node C responds by sending the appropriate
'responseOk'."

It should be better refined as "XML encoding" since there
is a chance of confusing with SOAP encoding.  The description
could be corrected with:

"Node A sends a message to node C with non-empty [XML encoding]
property. Node C responds by sending the appropriate
'responseOk'."

Also, Message A's XML encoding value of "UTF8" is incorrect.
It should be "UTF-8" instead.

---------------------
Test:T76
Second Message A's enc:ref="data" reference needs to have a
"#" prepended in front of "data", as in Test:T57.

---------------------

Test:TH5 (085)
The notion of "invalid" content-type value interpreted in SOAP 1.2
context is questionable.  SOAP connections and interpretations form
a subset of operations under the HTTP operating domain, triggered
by a content-type being specified as "application/xml+soap".
In a HTTP server capable of handling multiple POSTed content-types,
the interpretation of the POSTed content would have been dependent
on the content-type value specification sent by the connecting client.
If this content-type value has not been "application/xml+soap",
then the POSTed content may not have been interpreted as a SOAP
message in the first place.

In this example case, by definition, the relevant processing logic
would have been to invoke an application that would have been
capable of interpreting data of content-type "audio/mpeg".
Therefore, an error should have been then generated by that
audio/mpeg application instead of generating a HTTP error;
it need not be a HTTP error in the first place if the application
is successfully invoked by the HTTP server.


Thus, the Message C sample:

HTTP/1.1 415 Unsupported Media

should not be generated because the connection has not "bound" to 
SOAPv1.2 specification on HTTP-binding through the content-type 
using "application/xml+soap".  This test case, therefore,
does not test anything specific to SOAPv1.2.

It is therefore recommended that this test be excluded entirely
from this Test Specification.

---------------------
Test:SBR2-echoBoolean (099)
Message A's xsd type for <inputBoolean> should be "xsd:boolean".

---------------------
Test:SBR2-echoNestedStructResponse (103)
Message C's <return> tag's and its child, <varStruct>'s,
attributes "xsi:type" should hold the value "ns1:SOAPStruct"
instead of "ns1:SOAPStructStruct".

---------------------

Test:XMLP-10 (160)
The namespace values of Message A & C's "test" prefix appears
to be confusing when compared to the use of "test" in other tests.
This is also especially so when Message C's content defines
prefix "ns1" as
    xmlns:ns1="http://example.org/ts-tests/xsd"
and the namespace value of "test" is neither
   "http://soapinterop.org/" (prefix "sb" in other tests),
   or      "http://example.org/ts-tests"   (prefix "test" in other tests)

Either change all prefix of both Messages A & C's "test" to
"sb", and change "xmlns:test" to "xmlns:sb", or change all
occurrences of namespace values of "http://soapinterop.org/ts-tests"
to "http://example.org/ts-tests".  We favor the latter change.

So after a change to the latter, Messages A & C look like:

+.+.+.+.+.+.+.+.+.+.+.+.+.+.
Node A's Message:

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<env:Body>
  <test:echoSimpleTypesAsStructOfSchemaTypes 
   xmlns:test="http://example.org/ts-tests" 
   env:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
   <input1 xsi:type="xsd:int">42</input1> 
   <input2 xsi:type="xsd:float">0.005</input2> 
   <input3 xsi:type="xsd:string">hello world</input3> 
   <input4>Untyped information</input4> 
  </test:echoSimpleTypesAsStructOfSchemaTypes>
</env:Body>
</env:Envelope>

Node C's Message

<?xml version="1.0"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<env:Body>
 <test:echoSimpleTypesAsStructOfSchemaTypesResponse
   xmlns:test="http://example.org/ts-tests"
   xmlns:rpc="http://www.w3.org/2003/05/soap-rpc"
   env:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
   <rpc:result>return</rpc:result>
   <return xsi:type="ns1:SOAPStructTypes"
    xmlns:ns1="http://example.org/ts-tests/xsd">
    <type1 xsi:type="xsd:QName">xsd:int</type1>
    <type2 xsi:type="xsd:QName">xsd:float</type2>
    <type3 xsi:type="xsd:QName">xsd:string</type3>
    <type4 xsi:type="xsd:QName">xsd:anyType</type4>
   </return>
 </test:echoSimpleTypesAsStructOfSchemaTypesResponse>
</env:Body>
</env:Envelope>
+.+.+.+.+.+.+.+.+.+.+.+.+.+.
 
---------------------
Test:XMLP-12 (162)
Node C's response message does not contain RPC namespace
definition.

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Body>

should be:
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
  xmlns:rpc="http://www.w3.org/2003/05/soap-rpc">
<env:Body>

---------------------
Test:XMLP-18 (168)
Description says     '... and a role attribute with a value of "true".'
should be changed to '... and a relay attribute with a value of "true".'

[email]
Proposal:
Resolution:
You raised issue 19rec against the SOAP Version 1.2 Specification 
Assertion and Test Collection  document. The XMLP WG has closed issue 
19rec by accepting the proposal in the email at [3].
  
[email]
20recRECn/aClosedNoah Mendelsohn
Title: SOAP 1.2 and XML1.1
Description: See issue 458 of MTOM/XOP.
Now that XML 1.1 is a recommendation, and allows characters not allowed in
XML 1.0, it seems to me we need a review of our entire recommendation, as
well as XOP and MTOM drafts, to make sure we are clear on issues such as:

   Are the new control characters allowed by XML 1.1 allowed in XML SOAP
   Envelope infosets?  If so, do you indicate this in the version of the
   Infoset Document Information item?
   If allowed, I don't see how the HTTP binding would send them using the
   usual RFC 3203-based serialization, which my quick reading shows as XML
   1.0.
   We refer in the rec to XML 1.0 whitespace, but XML 1.1 allows NEL (x85)
   as whitespace.  Are we at least clear as to what is whitespace and what
   isn't for SOAP?
   Is it legal to write a new binding or media type that sends the new
   control chars, perhaps using XML 1.1 serialization?  This would seem to
   break the equivalence among bindings.
   We should similarly make sure XOP and MTOM are clear on these issues.


[email]
Proposal:
Resolution:
SOAP envelopes are XML 1.0 at the infoset level. application/soap+xml
remains 1.0 only and remains the only mandatory http media type. Other
bindings or media types MAY use XML 1.1 serialization to get the NEL char,
for example, but not to enable new element names, char content etc (at this
time). We will leave tracks in the rec resolution about the difficult
choice we made, perhaps contact the tag, and indicate that we can
reconsider when schema goes 1.1

The WG agreed to support this resolution by making changes to clarify the
statement within our documents.
On the 19th of May telcon, the XML Protocol WG voted to confirm the closure
of  issue Rec20 (SOAP 1.2 and XML 1.1) by adopting the following text
changes to the Part 1 errata:

   The proposal in
   http://lists.w3.org/Archives/Public/xml-dist-app/2004May/0026.html
   together with a link to the Binding Framework sectin when referring to
   XML 1.1
   The proposal in
   http://lists.w3.org/Archives/Public/xml-dist-app/2004Apr/0017.html
   The proposal in
   http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2004May/0033.html
   The proposal in
   http://lists.w3.org/Archives/Public/xml-dist-app/2004May/0028.html with
   the following modifications. Section 3.1 changes agreed as-is. Section
   4.3, last paragraph should say "MUST be serialized as
   application/soap_xop+xml" instead of "MUST be serialized as XML 1.0".
   Section 4.3.1.1, changing "The XOP Infoset MUST be serialized using XML
   1.0 in the root part of the package" to "The XOP Infoset MUST be
   serialized as application/soap_xop+xml in the root part of the package"
   The proposal in
   http://lists.w3.org/Archives/Public/xml-dist-app/2004May/0031.html with
   the inclusion of a reference to RFC 2732.

No changes will be made to the Part 2 errata.
  
[email]
21recpart2n/aClosedDaniel Barclay
Title: order of array dimension sizes
Description:
Some feedback regarding SOAP Version 1.2 Part 2:

Wording related to semantics:

* Section 3.1.6 doesn't say in which order array dimension sizes are listed.
   (It doesn't say whether the first size in the list is the size of the first
   dimension or is the size of the last dimension.)
  
[email]
Proposal:
Resolution:
You raised an issue which the XML protocols workgroup has tracked as its
issue 21 [1].  Specifically you said:

"* Section 3.1.6 doesn't say in which order array dimension sizes are
listed.(It doesn't say whether the first size in the list is the size of
the first dimension or is the size of the last dimension.)"

The workgroup agrees that this is a problem in the recommendation, and we
plan to resolve it with an erratum that says of the arraySize attribute:

"The arraySize attribute conveys a suggested mapping of a SOAP array to a
multi-dimensional program data structure.  The cardinality of the arraySize
list represents the number of dimensions, with individual values providing
the extents of the respective dimensions.  When SOAP encoding
multidimensional arrays, nodes are selected such that the last subscript
(I.e. the subscript corresponding to the last specified dimension) varies
most rapidly, and so on with the first varying most slowly.    An asterisk
MAY be used only in place of the first size to indicate a dimension of
unspecified extent;  asterisks MUST NOT appear in other positions in the
list.  The default value of the arraySize attribute information item is
"*", I.e. a single dimension of unspecified extent."

A bit of explanation.  In exploring this issue, we realized that the whole
notion of multi-dimensional array had not been introduced cleanly.  The
SOAP data model specifies only that entries are "distinguished by
position", with no hint of multiple dimensions.  We thus took the above
approach of making clear that while the SOAP data model is one dimensional,
the arraySize attribute provides a means of sending additional hints as to
how a multidimensional array may have been mapped to the single dimensional
SOAP array and corresponding encoding.
  
[email]
22recpart1n/aClosedMark Nottingham, Noah Mendelsohn
Title: Allowed characters in infoset for XML serialization
Description:
At the Cannes F2F, we identified an issue against SOAP 1.2. SOAP 
specifies that XML Infosets are the fundamental unit of messaging in 
SOAP, and that it's the binding's job to faithfully transport the 
Infoset.

However, there are some Infosets that bindings will not be capable of 
transporting, because different versions of XML are capable of 
serializing different ranges of Unicode characters. For example, an XML 
contains several control characters that are not legal in XML 1.0; 
furthermore, there are characters that are legal in an Infoset that 
cannot be serialized in any existing version of XML.

As a result, it may be necessary to clarify what SOAP1.2 is capable of 
transporting, and/or clarifying the responsibilities of a binding.


  
[email][email][email]
Proposal:
Resolution:
On the 19th May telcon, the XML Protocol WG voted to close issue Rec22
following the successful reolution and closure of issue Rec20.
  
[email]
23rectest colln/aClosedChin Chee-Kai
Title: SOAP 1.2 Test collection Errors (5)
Description:
Test:T53
Test:SBR1-echoDate (T96)

According to XML Schema, the type "xsd:dateTime" should be
normalized according to the REVERSE of the sign of the hours
indicated.  The current description performs directly the
arithmetic indicated instead of reversing them.

Strictly speaking, the test itself could spell out a test 
semantic that says, "in this test case, 'normalize' means
perform the arithmetic adjustments as manifested by the
unnormalized form", and there would be nothing "wrong"
about the test.

But the suggestion here is that it may be better to simply
follow what has been defined in XML Schema date-time normalization
as doing otherwise does not serve much of a point, and actually
tends to be confusing when the description does not indicate
a different way to normalize dateTime values from the way
specified by XML Schema.

Therefore, assuming the above correction of interpretation to
align with XML Schema's specification, Node C's response 
for both T53 and T96 should then be changed from:
+.+.+.+.+.+.+.+.+.+.+.+.+.+.
<return xsi:type="xsd:date">1956-10-18T15:20:00Z</return>
+.+.+.+.+.+.+.+.+.+.+.+.+.+.
to:
+.+.+.+.+.+.+.+.+.+.+.+.+.+.
<return xsi:type="xsd:date">1956-10-19T05:20:00Z</return>
+.+.+.+.+.+.+.+.+.+.+.+.+.+.
  
[email]
Proposal:
The type used in T53 [2] is "xsd:date" whereas the type used in 
SBR1-echoDate [3] is "xsd:dateTime". Therefore the proposal at [4] 
applies only to SBR1-echoDate and not to T53.

In addition, (a) the value of the attribute "xsi:type" in SBR1-echoDate 
is incorrect and should be changed from "xsd:date" to "xsd:dateTime", 
and (b) the value of element "inputDate" and "return" in T53 should be 
changed to "1956-10-18".


I would like to propose the following to resolve issue 23rec -

T53:
---

Replace "1956-10-18T22:20:00-07:00" in the message sent from Node A with 
"1956-10-18"
Replace "1956-10-18T15:20:00Z" in the message sent from Node C with 
"1956-10-18"

SBR1-echoDate:
-------------

Replace "xsd:date" in the message sent from Node A with "xsd:dateTime".
Replace "xsd:date" in the message sent from Node C with "xsd:dateTime".
Replace "1956-10-18T15:20:00Z" in the message sent from Node C with 
"1956-10-19T05:20:00Z"
[email]
Resolution:
You raised issue 23rec [1] against the SOAP Version 1.2 Specification
Assertion and Test Collection [2] document. The XMLP WG has closed issue
19rec by accepting the proposal in the email at [3].
  
24recpart0n/aClosedCarine Bournez
Title: (SOAP 1.2 part 0) typo in examples
Description:
Examples 14, 15, and 16 of the primer have a typo in a 
closing tag and say </reference> instead of </m:reference>
  
[email]
Proposal:
Resolution:
The XML Protocol WG decided to close this issue by accepting the proposed
changes. (</reference> will become </m:reference>)
  
[email]
25recpart2n/aClosedMark Nottingham
Title: SOAP 1.2 part 2, Appendix A: media type registration
Description:
Because of the decision of the WG to use an external media type 
registration for SOAP 1.2, this section needs to be updated to reflect 
the fact that the registration template in the REC is no longer 
normative.
  
[email]
Proposal:
This could be done by invalidating the entire appendix and pointing to 
the registration when it is published. Alternatively, we can update the 
registration template in the REC to match that which is registered, but 
we'll still need to point to the external document as normative.
  
[email]

NOTE: this issue will be evaluated once the registration of the media type is complete with IANA

Resolution:
The XML Protocol Working Group has resolved the issue [1] regarding the 
media type registration appendix in the SOAP 1.2 specifications. 
Specifically, the WG has decided to invalidate the entire appendix and 
update references from it to RFC3902 in errata.
[email]
26recpart2n/aClosedHugo Haas
Title: what is the "simple authentication feature"?
Description:
In section 7.5.1.2 of part 2, table 17 states for using 401:

| If the simple authentication feature is unavailable or the operation
| of simple authentication ultimately fails, then the message exchange
| is regarded as having completed unsuccessfully.

The document does not define nor reference a simple authentication
feature.

Doing a search for this "simple authentication feature", I found an
old draft of the HTTP binding, with an editor note saying:

| At present this is more of a hook, we have not (yet) described a
| simple authentication feature or an HTTP specific expression of that
| feature.


  
[email]
Proposal:
Resolution:
You raised issue 26 against the SOAP 1.2 Part 2 Recommendation: "The 
document does not define nor reference a simple authentication 
feature." The XMLP WG has decided to close this issue by removing the 
offending mention of a simple authentication feature from the document. 
Specifically we will issue errata to change the descriptive text to 
eliminate the reference to the feature but retain the row for the 401 
status code:

Current text: "Indicates that the HTTP request requires authorization. 
If the simple authentication feature is unavailable or the operation of 
simple authentication ultimately fails, then the message exchange is 
regarded as having completed unsuccessfully."

Modified text: "Indicates that the HTTP request requires authorization. 
The message exchange is regarded as having completed unsuccessfully."
[email]
27recpart2n/aClosedYves Lafon
Title: application/soap+xml "action" parameter
Description:
(from 
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=8198&rfc_flag=0)
The presence and content of the SOAPAction header field can be used by 
servers such as firewalls to appropriately filter SOAP request messages 
in HTTP. The header field value of empty string ("") means that the 
intent of the SOAP message is provided by the HTTP Request-URI. No value 
means that there is no indication of the intent of the message.

I assume that it is *not* intended that this parameter ever have an empty 
string as a valid value.  Given the parallel made in the text, though, I 
believe it would be valuable to make explicit that this is or is not 
permitted.  I also note that the filtering text almost certainly does not 
belong in this registration. (as it conflicts with the statement in the 
security considerations)
  
[email]
Proposal:
Resolution:
In Part2, section 6.5.3
replace
<
The SOAP Action feature defines a single property, which is described in
Table 14. >
by

>The SOAP Action feature defines a single property, which is described in
Table 14. The value of this property MUST be an absolute URI [rfc2396] and
MUST NOT be empty.<
[email]
28recXOPn/aClosedRyan Hayes
Title: Bad anchor in XOP
Description:
In the first paragraph of section 1 of "XML-binary Optimized
Packaging" there is an anchor whose title is [XMLInfoSet] and whose
href URI is "#", however, I'm presuming that the href URI should be
"#XMLInfoset".
  
[email]
Proposal:
Resolution:
The working group decided to add the suggested fix in the XOP 1.0 Errata 
[1]. It will be included when a new edition of the XOP 1.0 Recommendation 
will be issued.
[email]
29recRRSHBn/aClosedSimon Kissane
Title: non-normative example in RRSHB
Description:
My interpretation of the "Resource Representation SOAP Header Block"
is that section 4.3.3 is non-normative, which I believe is the
interpretation everyone would agree with. However, the first time I
read it, I formed the impression that the "HTTP resolver"
functionality in it was some form of optional part of the
specification. I might suggest, that to avoid any such impression
being formed in the minds of a less than careful reader, that the
section be moved to an appendix and clearly marked as "NON-NORMATIVE".
(At first, I read the wording "Extension example:"  to mean, not that
this section is non-normative, but that this part of the specification
is an example of the power of the extensibility mechanisms in the
specification.)

Also, I could not find a public comment email address, or editors
email addresses, for this specification, so I am reporting it here. Is
this the right place? I would suggest that every recommendation should
clearly identify in its introduction how errata or other such issues
are to be raised.
  
[email]
Proposal:
Resolution:
In section 1.1, you may find:

<<
All parts of this specification are normative, with the exception of 
examples and sections explicitly marked as "Non-Normative".
>>

So, examples are explicitely non-normative. As 4.3.3 is clearly labelled 
as being an example, it is by definition non-normative.
So the Working Group decided to close this issue with no actions taken, as 
the specification is clear enough on the status of section 4.3.3.

[email]
30rectest colln/aClosedAnish Karmarkar
Title: Errors in test collection
Description:
While merging the errata [1] into the test collection document [2]. I 
found the following two issues:

1) In test T73 the message sent from Node C does not have the 'xsd' 
prefix declared.
Fix --
   add the prefix -- xmlns:xsd="http://www.w3.org/2001/XMLSchema"

2) In test T45, message sent from Node C has an incorrect type for the 
element 'varStruct.
Fix --
   <varStruct xsi:type="ns1:SOAPStructStruct">
   should be replaced by
   <varStruct xsi:type="ns1:SOAPStruct">
  
[email]
Proposal:
See above.
Resolution:
The XMLP WG decided in its Feb 9th 2005 concall [2] to close Rec issue 30
[1] with the proposed resolution in [3].
[email]
31recpart1n/aClosedMark Baker
Title: soap:body and media types
Description:
Something Noah Mendelsohn said at the technical plenary week about SOAP
& media types, made me realize that the SOAP envelope currently has a
problem; that it cannot communicate the media type of the document
encapsulated within the SOAP body.

It seems that "namespace dispatch" is implicit in SOAP, as the namespace
of the root element of the encapsulated document is used to infer the
intended semantics of that document.  However that approach has several
problems, including security, performance (both as a result of poor
layering), as well as expressibility; of being unable to, for example,
communicate the difference in semantics of an XHTML document and an XSLT
simplified stylesheet[1].

A fix would be to provide a standardized "Content-Type" header so one
could say;

  <env:Envelope xmlns="..."
    <env:Header>
      <foo:Content-Type mustUnderstand="true">application/xhtml+xml</foo:Content-Type>
    </env:Header>
    <env:Body>
      <html xsl:version="1.0"
            xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
            xmlns="http://www.w3.org/TR/xhtml1/strict">
      ...

Of course, it would have to use a mandatory extension in the case where
it's being used to address the problem I described above, otherwise
receiving agents would be licensed to assume namespace dispatch.
[email]
Proposal:
Resolution:
You sent e-mail[1] to the XMLP comments list which resulted in Rec Issue
31[2] being entered into the issues list. The XMLP WG has considered
your comments and concluded that it is not appropriate to address this
comment in a Proposed Edited Recommendation or Second Edition of SOAP
1.2. It is also not clear that the XMLP WG is the most appropriate place
to deal with this issue, which, as you allude to, is not unique to SOAP.


Thus the XMLP WG is not going to take any action regarding this issue.
[email]
32recxop,mtom,soap12-part0n/aClosedMark Baker
Title: Use of "xmlmime" namespace prefix in XOP examples
Description:
I note that XOP uses an "xmlmime" namespace prefix in its examples,
despite namespace prefix names beginning with "xml" being reserved for
use by the XML Rec proper.  Though non-normative, I think this is worth
an errata, to dissuade folks from making the same mistake.
  
[email]
Proposal:
Resolution:
The Working Group decided to document the change from xmlmime: to xmime: 
in the errata, as well as in the example of the upcoming new version of 
the SOAP Version 1.2 part 0: Primer.
[email]
33recsoap12-part2n/aClosedAnish Karmarkar
Title: Behavior of Requesting node on a 3XX response in the SOAP HTTP Binding
Description:
Table 17 in [1] lists the following as the 'Significance/Action' on
receiving a 3XX status code --

"The requested resource has moved and the HTTP request SHOULD be retried
using the URI carried in the associated Location header field as the new
value for the http://www.w3.org/2003/05/soap/mep/ImmediateDestination
property."

and the next state defined is: "Init"

It is unclear what this means for the
"http://www.w3.org/2003/05/soap/mep/request-response/" MEP. There are
several 3XX status codes which require different behavior (per HTTP).
Specifically, 303 requires the requester to use the GET method on the
resource, whereas typically for a 307 the requester will re-POST the same
message at the new URI available in the Location HTTP header.

If the requester uses a GET method on a 303, is the MEP still the
request-response MEP? Table 16, (which describes the fields in the Init
state), specifies that the HTTP method is set as per the
"http://www.w3.org/2003/05/soap/features/web-method/Method" which is
unchanged after the 3XX response (the only thing that changes is the
'ImmediateDestination'). OR if a requester uses the GET method on receiving
a 303 is it conformant to the SOAP HTTP binding as defined by SOAP 1.2, part
2: Adjunct. There seems to be conflict in trying to remain conformant to the
HTTP spec and the SOAP HTTP binding when a 303 is received.

It seems to me that an errata that clarifies that a 3XX may change the value
of "http://www.w3.org/2003/05/soap/features/web-method/Method" would allow
implementations to be conformant to the HTTP spec and the SOAP HTTP binding.

  
[email]
Proposal:
Resolution:
The working group decided to close the issue with the following 
resolution:

In part2, Table 17:
Add the following line
{
Status Code:
303

Reason Phrase:
See Other

Significance/Action:
The requested resource has moved and the HTTP request SHOULD be retried
using the URI carried in the associated Location header field as the new
value for the http://www.w3.org/2003/05/soap/mep/ImmediateDestination
property. The value of
http://www.w3.org/2003/05/soap/features/web-method/Method is changed to
"GET", the value of http://www.w3.org/2003/05/soap/mep/OutboundMessage is
set to null. [Note: Status code 303 MUST NOT be sent unless the request 
SOAP envelope has been processed according to the SOAP processing model 
and the SOAP response is to be made available by retrieval from the URI
provided with the 303.]

Next Step:
Init
}

The "3xx" line should be replaced by the following:
{
Status Code:
301,302,307

Reason phrase:
"Redirect"

Significance/Action:

The requested resource has moved.
In the case of unsafe HTTP method, like POST or PUT, explicit confirmation
is required before proceeding as follow.
In the case of a safe method, like GET, or if the redirection has been
approved, the HTTP request SHOULD be retried using the URI carried in the
associated Location header field as the new value for the
http://www.w3.org/2003/05/soap/mep/ImmediateDestination property.

NextState:
"Init" or "Fail"
}

[email]
34recxopn/aClosedJonathan Marsh
Title: start-info vs. startinfo
Description:
XOP [1] refers to the "startinfo" parameter in the text and in examples,
yet RFC 2387 [2] defines the "start-info" parameter.  I believe XOP
should be corrected to use the latter (add the hyphen) throughout.
  
[email]
Proposal:
Resolution:
All the occurences of "startinfo" will be replaced by "start-info". The 
replacement locations are:
- XOP, section 1.2 Example, in Example 2.
- MTOM, section 3.2 Serialization of a SOAP message, third bullet.
[email]
35recxopn/aClosedJonathan Marsh
Title: Use absolute URIs for action parameter in examples
Description:
XOP [1] illustrates the use of the action parameter with the value
"ProcessData", yet SOAP 1.2 Adjuncts [2] says the value must be an
absolute URI.  I believe XOP should be corrected to use a value such as
"http://example.org/ProcessData".
  
[email]
Proposal:
Resolution:
The action parameter, as defined in SOAP 1.2 Adjuncts [2] must have as 
value an absolute URI. Therefore its two occurences in XOP, section 1.2 
Example, Example 2, will be modified to be:

action=\"http://www.example.com/ProcessData\"

[email]
36recxop/mtomn/aClosedAlessandro Triglia
Title: Possible defect in XOP and MTOM (xs:base64Binary)
Description:
I am reading www.w3.org/TR/xop10/ and it seems to me that something is missing in the following clause:


-----------------------------------
3.1 Creating XOP Packages

To create a XOP Package from an Original XML Infoset: 

[...]

Identify within the Original XML Infoset the element information items to be optimized. To be optimized, the characters comprising the [children] of the element information item MUST be in the canonical form of xs:base64Binary (see [XML Schema Part 2: Datatypes Second Edition]3.2.16 base64Binary) and MUST NOT contain any whitespace characters, preceding, inline with or following the non-whitespace content. 

[...]
-----------------------------------


I would assume that the first condition to be imposed is that the [children] of the element information item be all character information items.  For example, comment IIs and processing instruction IIs present among the [children] -- in any position -- should prevent the "optimization", as do the character IIs that are whitespace.  

(That an element II present among the [children] should also prevent the optimization is even more obvious.)

Perhaps this condition is kind-of implied by the use of the term "comprising" (instead of "among", say), but I think the condition should be stated more explicitly.

A similar problem exists in MTOM (clause 2.3.1).
  
[email]
Proposal: See [email] and [email]
Resolution:
Updated text:

3. Identify within the Original XML Infoset the element information 
items to be optimized. To be optimized, the characters comprising the 
[children] of the element information item MUST be in the canonical form 
of xs:base64Binary (see [XML Schema Part 2: Datatypes Second 
Edition]3.2.16 base64Binary) and MUST NOT contain any whitespace 
characters, preceding, inline with or following the non-whitespace 
content. Note that this rule requires that the [children] of the element 
information item to be optimized contains only character information 
items.
[email]
37rectest colln/aClosedAnish Karmarkar
Title: Bugs in tests T27 and T58
Description:
Tests T27 [1] and T58 [2] consists of node A sending a message that 
contains an incorrect type/value. Test 27 contains an array with 
declared itemType of xs:string but contains a complex type. Test T58 
contains an array with declared itemType of xs:int but contains a 
complex type.

SOAP 1.2 part 2, section 4.4 [3] says:
"A fault with a Value of Code set to "env:Sender" and a Value of Subcode 
set to "rpc:BadArguments" MUST be generated when the receiver cannot 
parse the arguments or when there is a mismatch in number and/or type of 
the arguments between what the receiver expects and what was sent."

But both tests T27 and T58 do not have a Subcode in the fault sent from 
node C to node A.

Note that test XMLP-11 [4] consists of a similar situation and node C 
sends the correct fault Subcode (rpc:BadArguments).

For implementations to consistently and correctly generate Fault 
Subcodes, I would like to suggest that T27 and T58 be modified to 
include the following Fault Subcode in the message from node C to node A:
-----
         <env:Subcode>
           <env:Value xmlns:rpc="http://www.w3.org/2003/05/soap-rpc">
             rpc:BadArguments
           </env:Value>
         </env:Subcode>
-----
  
[email]
Proposal:
For implementations to consistently and correctly generate Fault 
Subcodes, I would like to suggest that T27 and T58 be modified to 
include the following Fault Subcode in the message from node C to node A:
-----
         <env:Subcode>
           <env:Value xmlns:rpc="http://www.w3.org/2003/05/soap-rpc">
             rpc:BadArguments
           </env:Value>
         </env:Subcode>
-----
[email]
Resolution:
The WG decided last week to close issues Rec37 by accepting your 
proposed text, more precisely:

For tests T27 and T58
Inclusion of he following Fault Subcode in the message from node C to node A:
-----
          <env:Subcode>
            <env:Value xmlns:rpc="http://www.w3.org/2003/05/soap-rpc">
              rpc:BadArguments
            </env:Value>
          </env:Subcode>
-----
[email]
38rectest colln/aClosedAnish Karmarkar
Title: Bugs in T38
Description:
T38 consists of messages that are sent from node A to node C, with node 
C responding back to node A. The messages sent by node A use different 
lexical representations for the values of the MU attribute (true, false, 
1, 0). But the role value for the test:Unknown header block in the first 
message from A and the test:echoOK header block in the 2nd message from 
A is "http://example.org/ts-tests/B". This is a bug as node B is not 
involved in this test. The correct value should either be 
"http://example.org/ts-tests/C" or the role attribute should be omitted.
  
[email]
Proposal:
Resolution:
The Working Group decided to close T38 with your first proposal:

The correct value should be "http://example.org/ts-tests/C
[email]
39recpart2n/aClosedYves Lafon
Title: Optionality of SOAP response in HTTP binding
Description:
When using the SOAP HTTP binding, and the request-response MEP,
is it required that the SOAP response be sent over the HTTP response for
the success case?
  
[email]
Proposal:
Resolution:
At the 07-dec-2005 concall the XMLP WG decided to close issue Rec39 [1] 
by including the requirement for an optional-response/empty HTTP 
entity-body in the new MEP/binding work that the WG is undertaking.

The WG also decided that per the existing binding defined in SOAP 1.2 
[2], it is not possible to send back an empty HTTP entity body for the 
non-fault case when using the request-response MEP. The reasons for this 
are listed in the email at [3].
[email]
40recxopn/aClosedJonathan Scott
Title: Invalid cid URI syntax in xop:include examples
Description:
In the "XML-binary Optimised Packaging" specification at 
http://www.w3.org/TR/xop10/ the syntax of the href attribute on 
xop:include is defined in section 4.1 to use the "cid:" form of URI as 
specified by RFC 2392.  However, in the examples, the href attribute is 
shown with values consisting of "cid:" prefixed to an HTTP URI, which as 
far as I know is not syntactically valid according to RFC 2392.  According 
to this RFC, a cid URL is syntactically equivalent to an RFC822 e-mail 
address, in the general form local-part@domain.
  
[email]
Proposal:
In section 1.2 Example of XOP [2], modify Example 2 and Example 4, by 
changing the following 'cid:' URIs:

cid:http://example.org/me.png -> cid:mypicture.png@example.org
cid:http://example.org/my.hsh -> cid:mysignature.hsh@example.org

and by changing the following 'Content-ID' fields:

Content-ID: <http://example.org/me.png> ->
	Content-ID: <mypicture.png@example.org>
Content-ID: <http://example.org/my.hsh> ->
	Content-ID: <mysignature.hsh@example.org>
[email]
Resolution:
In section 1.2 Example of XOP [2], modify Example 2 and Example 4, by
changing the following 'cid:' URIs:

cid:http://example.org/me.png -> cid:mypicture.png@example.org
cid:http://example.org/my.hsh -> cid:mysignature.hsh@example.org

and by changing the following 'Content-ID' fields:

Content-ID: <http://example.org/me.png> ->
        Content-ID: <mypicture.png@example.org>
Content-ID: <http://example.org/my.hsh> ->
        Content-ID: <mysignature.hsh@example.org>
[email]
41recpart1n/aClosedNoah Mendelsohn
Title: Possible bug in SOAP 1.2 description of fault generation
Description:
While reviewing the processing model section of SOAP 1.2 [1], I noticed 
that it says:

"Failure is indicated by the generation of a fault (see 5.4 SOAP Fault). 
SOAP message processing MAY result in the generation of at most one 
fault."

Taken literally, that seems to say:  "you probably want to generate at 
most one fault, but we don't strictly preclude the alternative, which 
would be generating more than one fault."   That's not what we meant. I 
think what we intended would be better covered by either of the following 
two rewordings:

* "Failure is indicated by the generation of a fault (see 5.4 SOAP Fault); 
SOAP message processing MUST result in the generation of at most one fault 
for each message processed."

-or-

* "Failure is indicated by the generation of a fault (see 5.4 SOAP Fault). 
SOAP message processing MAY result in the generation a SOAP fault; more 
than one SOAP fault MUST NOT be generated when processing a SOAP message."

Note that in any case, the paragraph that follows correctly says:

"A message may contain or result in multiple errors during processing. 
Except where the order of detection is specifically indicated (as in 2.4 
Understanding SOAP Header Blocks), a SOAP node is at liberty to reflect 
any single fault from the set of possible faults prescribed for the errors 
encountered. The selection of a fault need not be predicated on the 
application of the "MUST", "SHOULD" or "MAY" keywords to the generation of 
the fault, with the exception that if one or more of the prescribed faults 
is qualified with the "MUST" keyword, then any one fault from the set of 
possible faults MUST be generated."

I don't think anyone is confused about what we meant, which is: generate 
at most one fault.  I wonder whether a rewording should be issued with the 
next set of errata?  Does anyone remember if there was a reason we worded 
it this way?  Thanks.
  
[email]
Proposal:
Resolution:
In response to the issue [1] raised by Noah, and commented on by Henrik 
[2], the XMLP WG has concluded that 
it prefers the second of the two alternative proposals:

"Failure is indicated by the generation of a fault (see 5.4 SOAP Fault). 
SOAP message processing MAY result in the generation a SOAP fault; more 
than one SOAP fault MUST NOT be generated when processing a SOAP message."
[email]
42recxop,mtom,rrshbn/aClosedHerv頒uellan
Title: XOP, MTOM and RRSHB editorial issues
Description:
1. Spurious '>'
---------------
In the xop prefix notes table cell, in 1.3 Notational Conventions, there 
are several '>' characters that should not be there.

Solution:
Remove those characters.

2. xmlmime URI in XOP
---------------------
The Describing Media Content of Binary Data in XML document is now 
published as a WG Note. We should update the XOP recommendation accordingly.

Solution:
Replace xmlmime by xmime (9 occurences).
Replace http://www.w3.org/2004/11/xmlmime by 
http://www.w3.org/2005/05/xmlmime (3 occurences).
Remove the Editorial note in 1.3
Update the reference in B.1 Normative References.

3. xmlmime URI in RRSHB
---------------------
The Describing Media Content of Binary Data in XML document is now 
published as a WG Note. We should update the RRSHB recommendation 
accordingly.

Solution:
Replace xmlmime by xmime (6 occurences).
Replace http://www.w3.org/2004/11/xmlmime by 
http://www.w3.org/2005/05/xmlmime (3 occurences).
Update the reference in A References.

4. Schema for http://www.w3.org/2004/08/representation
------------------------------------------------------
In 1.1 Notational Conventions, the description of the rep prefix refers 
to the schema document by naming the link TBD. Moreover, the document 
linked is not a schema document.

Solution:
Change TBD to http://www.w3.org/2004/08/representation
Change the document to be the actual schema (do we ever write this schema?).

5. Normative schema for RRSHB
-----------------------------
In both MTOM 1.1 Notational Conventions and RRSHB [3] 1.1 Notational 
Conventions, we speak of the *normative* schema for RRSHB. Was it really 
our intention? From my understanding, the group position was that 
defining in two normative way the same thing was dangerous and that 
having informative schema was better.

Solution:
Declare the RRSHB schema to be non-normative.
[email]
Proposal:
Resolution:
The XMLP WG decided to close issue rec42 with the following resolution:

> Here is the list of issues with proposed solutions.
>
> 1. Spurious '>'
> ---------------
> In the xop prefix notes table cell, in 1.3 Notational Conventions, there are 
> several '>' characters that should not be there.
>
> Solution:
> Remove those characters.

Done (in fact it was an artefact of spec generation)

> 2. xmlmime URI in XOP
> ---------------------
> The Describing Media Content of Binary Data in XML document is now published 
> as a WG Note. We should update the XOP recommendation accordingly.
>
> Solution:
> Replace xmlmime by xmime (9 occurences).
> Replace http://www.w3.org/2004/11/xmlmime by 
> http://www.w3.org/2005/05/xmlmime (3 occurences).
> Remove the Editorial note in 1.3
> Update the reference in B.1 Normative References.

Done, see edcopy [4] and errata [5].


> 3. xmlmime URI in RRSHB
> ---------------------
> The Describing Media Content of Binary Data in XML document is now published 
> as a WG Note. We should update the RRSHB recommendation accordingly.
>
> Solution:
> Replace xmlmime by xmime (6 occurences).
> Replace http://www.w3.org/2004/11/xmlmime by 
> http://www.w3.org/2005/05/xmlmime (3 occurences).
> Update the reference in A References.

Done, see edcopy [6] and errata [7].

> 4. Schema for http://www.w3.org/2004/08/representation
> ------------------------------------------------------
> In 1.1 Notational Conventions, the description of the rep prefix refers to 
> the schema document by naming the link TBD. Moreover, the document linked is 
> not a schema document.
>
> Solution:
> Change TBD to http://www.w3.org/2004/08/representation
> Change the document to be the actual schema (do we ever write this schema?).

Done, see edcopy. Link at http://www.w3.org/2004/08/representation points 
to the corrected schema.

> 5. Normative schema for RRSHB
> -----------------------------
> In both MTOM 1.1 Notational Conventions and RRSHB [3] 1.1 Notational 
> Conventions, we speak of the *normative* schema for RRSHB. Was it really our 
> intention? From my understanding, the group position was that defining in two 
> normative way the same thing was dangerous and that having informative schema 
> was better.
>
> Solution:
> Declare the RRSHB schema to be non-normative.

The WG decided to leave the current text as-is, ie: felt that it was not 
needed to state that the specification takes precedence over the schema.

[email]
43recpart2n/aClosedMark Baker
Title: SOAP 1.2 Adjuncts errata re GET support
Description:
"For example, a conventional Web server (i.e. one not written
specifically to conform to this specification) might be used to
respond to SOAP-initiated HTTP GET's with representations of
Content-Type "application/soap+xml". Such interoperation is not a
normative feature of this specification."
 -- http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#httpinterop

But of course, the WebMethod feature supports exactly that (unless I'm
misunderstanding what "SOAP-initiated" means).

I expect this wasn't removed/replaced after the (late) addition of the
WebMethod feature.
	
[email]
Proposal:
Resolution:
Based on the discussion on this thread, the Working Group decided to close 
your issue [1] with no action.
[email]

Table Legend

id
Issue number
Title
Short title/name of the issue
Spec
Document referred to in issue (AM = Abstract Model, Spec = XMLP/SOAP Specification
Description
Short description of issue, possibly including link to origin of issue
Req
Link to XML Protocol Requirement that motivated this issue
Topic
Rough topic categorisation, one of: env(elope), rpc, enc(oding), meta(issue), bind(ing), fault
Class
Design or Editorial
Status
One of: Unassigned, Active, Closed, Postponed
Proposal
Current proposal for resolution of issue, possibly including link to further text
Resolution
Short description of resolution, possibly including link to a more elaborate description
Raised by
Person who raised the issue
Owner
XML Protocol WG Member responsible for the issue

Maintained by Yves Lafon.