"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]
Based on the discussion on this thread, the Working Group decided to close your issue [1] with no action.[email]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
The Working Group decided to close T38 with your first proposal: The correct value should be "http://example.org/ts-tests/C[email]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
See above.
The XMLP WG decided in its Feb 9th 2005 concall [2] to close Rec issue 30 [1] with the proposed resolution in [3].[email]
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]
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]
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]
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]
(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]
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]
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]
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]
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]
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
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]
Examples 14, 15, and 16 of the primer have a typo in a closing tag and say </reference> instead of </m:reference>[email]
The XML Protocol WG decided to close this issue by accepting the proposed changes. (</reference> will become </m:reference>)[email]
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]
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]
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].
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]
On the 19th May telcon, the XML Protocol WG voted to close issue Rec22 following the successful reolution and closure of issue Rec20.[email]
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]
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]
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]
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]
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]
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]
============================== 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.xml,v 1.74 2007/06/20 15:01:52 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.xml,v 1.74 2007/06/20 15:01:52 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.xml,v 1.74 2007/06/20 15:01:52 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]
he XML Protocol WG decided to close issue Rec18 by accepting the changes proposed by the originator.[email]
The references to SOAP 1.1 in the various SOAP 1.2 documents need to be fixed.[email]
=================================================== 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]
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]
Line 22 of the schema [3] is changed: <xs:element name='result' /> to <xs:element name='result' type='xs:QName'/>[email]
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]
The XMLP WG has decided to close this issues by accepting the suggested change.[email]
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]
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]
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]
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
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]
Remove the diff markup as suggested.email
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]
[..] 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]
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]
------------------------------ *********************** * 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":[email]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.
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]
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]
(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]
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].
(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]
The XMLP WG has decided to close this issues with the resolution proposed in Anish's email[email
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-. > 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]
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]
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]
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]
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> <?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> ----------------------.............................................^missing double-quote[email]
The XMLP WG has decided to add the missing double quote per your suggestion.[email]
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]
The XMLP WG has decided to accept your "each such feature" correction.[email]
Both SOAP 1.2 part 1 and part 2 mention viability in the copyright statement where I believe liability is meant.[email]
The XMLP WG has decided to change "viability" to "liability" in Parts 1 and 2 per your suggestion.[email]
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]
The XMLP WG has decided to accept your proposed resolution issue 1[email]