Issues regarding the documents produced but the XML Protocol Working Group should be reported to xmlp-comments@w3.org (public archives).
Comments on this list should be sent to the xml-dist-app@w3.org mailing list (Archives).
In this document, AMG means abstract model group, RPCTF means RPC task force, TBTF means transport binding task force and ETF means encoding task force.
For the previous list of closed and postponed issues, you can read the WG issue list.
id | Status | Spec | Topic | Class | Req | Title |
---|
id | Spec | Req | Topic | Class | Status | Raised By | Owner |
---|---|---|---|---|---|---|---|
206 | spec | n/a | rpc | Design | Closed | Christopher Ferris | |
Title: resolution to rpc:ProcedureNotFound fault subcode | |||||||
Description:
Although the WG agreed to the s/MUST/MAY/ resolution for the rpc:ProcedureNotFound fault subcode as described in [0], subsequent discussion on this thread suggested that there may be support for removal of the rpc:ProcedureNotFound fault subcode and the establishment of a more generalized fault subcode that would apply in all cases, not just RPC.[email] |
|||||||
Proposal: | |||||||
Resolution:
During the XMLP Telcon on 4th July 2002, to close the Issue record [1] without modification to the specifications on the grounds that: a) the current solution is not broken and b) does not prohibit the definition of a more generic fault subcodes by others.[email] |
|||||||
207 | spec | n/a | Binding | Design | Closed | Mark Baker | |
Title: Is RFC 822/2822 binding a protocol binding? | |||||||
Description:
Last week at WWW2002, Rohit Khare mentioned something that I believe demonstrates why a RFC 822/2822 binding is not a protocol binding. During one of our Developers Day protocols panels, he suggested that the behaviour of the "Bcc" header depended upon the semantics with which the message was transferred. For example, if a message that was constructed with this SMTP binding were transferred with HTTP (a perfectly valid thing, since HTTP also uses RFC 822), then the Bcc header would be passed through, rather than being treated as hop-by-hop. The processing of Bcc in the expected way *requires* that it and the message be tranferred with email semantics. The only way that this can currently be done, since there exists no abstract description of what an email binding entails, is to bind the message to an email transfer protocol. I don't particularly care which one is used, though I believe SMTP is the only widely deployed standardized one.[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP WG has decided to close issue 207 with no further action, considering the Email binding is fine as is, and you were the only proponent for that call and said you could live with it.[email] |
|||||||
208 | spec | n/a | meta | Design | Closed | Noah Mendelsohn | |
Title: Clarify that whitespace IS (potentially) significant in Header and Body blocks | |||||||
Description:
> Section 5, Section 5.2.1, Section 5.3.1: > Clarify that whitespace IS (potentially) significant in Header and > Body blocks. Changes are needed at the very end of section 5.0. > Also, 5.2.1 and 5.3.1 should be brought in line with the conventions > established for 5.4.5.1, etc., which talk about character children and > whitespace. > +1, but I think that this may need some discussion. I think the last paragraph of 5.0 is OK as it says "Unless otherwise indicated...". I've added a bullet to 5.2.1 and 5.3.1 noting that whitespace is significant. Question: Is whitespace within the Body significant or only within children of the body ? At the moment we only state the latter.[email] |
|||||||
Proposal: | |||||||
Resolution:
The text of the LC WD is has improved clarity regarding the significance of whitespace. The WG will add an extra bullet, saying whitespaces is insignificant except where specified otherwise. The WG decided this is an editorial issue. [Aside: The record is does not say where this bullet will be added, but I believe it be in Part 1 Section 5.0] |
|||||||
209 | spec | n/a | Encoding | Design | Closed | Noah Mendelsohn | |
Title: scoping rules for encodingStyle | |||||||
Description:
> Section 5.1.1: > The encodingStyle attribute SHOULD NOT appear on the SOAP > Envelope [reference to 5.1], SOAP Body [reference to 5.3] or SOAP > Header [reference to 5.2] element information items. Not sure whether this should be a MUST because of the scoping rules for encodingStyle ?[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP WG has decided to close issue 209 by changing the SHOULD to a MUST, in order to bring the text in agreement with the schema. It considers this issue is editorial in nature./[email] |
|||||||
210 | spec | n/a | meta | Design | Closed | Noah Mendelsohn | |
Title: Don't we allow arbitrary attributes on header blocks? | |||||||
Description:
Section 5.2.1 (and 5.3.1): (Don't we allow arbitrary attributes on header blocks? This may need to be a last call issue. Still, I'm curious whether we ever intended to rule these out? The equivalent issue exists for Body child elements, IMO.) <original> Each SOAP header block element information item: * MUST have a [namespace name] property which has a value, that is, be namespace qualified. * MAY have an encodingStyle attribute information item in its [attributes] property. * MAY have an role attribute information item in its [attributes] property. * MAY have a mustUnderstand attribute information item in its [attributes] property. </original>[email] |
|||||||
Proposal:
<suggested> Each SOAP header block element information item: * MUST have a [namespace name] property which has a value, that is, be namespace qualified. ** May have zero or more attribute information items. Among these MAY be any or all of the following, which have special significance for SOAP processing: - encodingStyle attribute information item - role attribute information item - mustUnderstand attribute information item </suggested> |
|||||||
Resolution:
The XMLP WG has decided to close issue 210 by accepting your text. The change is as follows: <newText> Each SOAP header block element information item: MUST have a [namespace name] property which has a value, that is, MUST be namespace qualified. MAY have any number of character information item children. Child character information items whose character code is amongst the whitespace characters as defined by [XML 1.0] are considered significant. MAY have zero or more attribute information items in its [attributes] property. Among these MAY be any or all of the following, which have special significance for SOAP processing: - encodingStyle attribute information item (see 5.1.1 SOAP encodingStyle Attribute). - role attribute information item (see 5.2.2 SOAP role Attribute). - mustUnderstand attribute information item (see 5.2.3 SOAP mustUnderstand Attribute). </newText>[email] |
|||||||
211 | spec | n/a | Editorial | Design | Closed | Noah Mendelsohn | |
Title: Define "abstract piece of functionality" | |||||||
Description:
Section 1.4 (and 3.1): "SOAP feature: An abstract piece of functionality..." (what is an abstract piece of functionality?...same phrase appears in 3.1)[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP WG has decided to close issue 211 with the following editorial change: Section 1.4 (and 3.1): "SOAP feature: An abstract piece of functionality..." was changed to: "SOAP feature: An extension of the SOAP messaging framework...".[email] |
|||||||
212 | spec | n/a | binding | Design | Closed | Noah Mendelsohn | |
Title: Error handling or processing of externally expressed features | |||||||
Description:
Section 3.1: (AMBANT (the word "it") and generally a bit awkward.) <original> While the SOAP Protocol Binding Framework provides for the possibility that such features may be expressed outside the SOAP envelope, it does not define a specific architecture for the processing or error handling of these externally expressed features by a SOAP intermediary. </original>[email] |
|||||||
Proposal:
<suggested> Although the SOAP Protocol Binding Framework allows end-to-end features to be expressed outside the SOAP envelope, no standard mechanism is provided for the processing by intermediaries of the resulting messages. </suggested> |
|||||||
Resolution:
The XMLP WG had decided to close action 212 by incorporating your suggested change. It considers this issue is editorial in nature.[email] |
|||||||
213 | spec | n/a | Editorial | Design | Closed | Noah Mendelsohn | |
Title: Special rules for MEPs | |||||||
Description:
Section 3.3: relationship to section 3.1.1 is awkward. Both establish special rules for MEPs. Suggest that all description of special rules for MEPs be in one place or the other.[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP WG has decided to close issue 213 with the following editorial change: Moved MEP specific rules to section 3.3 (dropping from 3.1.1).[email] |
|||||||
214 | spec | n/a | Editorial | Design | Closed | Noah Mendelsohn | |
Title: The final reference to "false or 0" seems to violate our style guideline | |||||||
Description:
Section 5.2.3: (the final reference to "false or 0" seems to violate our style guideline, I.e. that we never talk about multiple lexical forms, unless it matters. In the first sentence it does matter, in the 2nd it doesn't. Still, I'm not sure I'd make that part of the change.) <original> If relaying the message, a SOAP intermediary MAY substitute "true" for the value "1", or "false" for "0". The SOAP mustUnderstand attribute information item may be omitted if its value would have been "false" or "0". </original>[email] |
|||||||
Proposal:
<suggested notSureWeShouldChange="true"> If relaying the message, a SOAP intermediary MAY substitute "true" for the value "1", or "false" for "0". The SOAP mustUnderstand attribute information item may be omitted from the relayed message if its value would have been "false". </suggested> |
|||||||
Resolution:
The XMLP WG has decided to close issue 214 with the following resolution: In Section 5.2.3, the final reference to "false or 0" violated our style guideline (only referring to multiple lexical values if it really matters). Your suggested text change was made (removing 'or "0"'). In addition, a similar entry two paragraphs above was made. |
|||||||
215 | spec | n/a | meta | Design | Closed | Noah Mendelsohn | |
Title: The role EII must be one of the roles assumed by the node during processing? | |||||||
Description:
> Section 5.4.4: > What do we mean "similar"? They are as different as the > definition of a variable and a reference to that variable. > <original> > The Role element information item is similar to the SOAP role > attribute information item (see 5.2.2 SOAP role Attribute), > except that the value of the Role element information item > identifies the role the node was playing at the point the fault > occurred. </original> > <suggested> > The Role element information identifies a role the node was > playing at the point the fault occurred. This MUST BE one of the > roles assumed by the node during processing of the message [ref > to section 2.6]. > </suggested> Partly done. I removed the "is similar to the SOAP role attribute information item (see 5.2.2 SOAP role Attribute), except that the value of the Role element information item". I did not add the sentence "This MUST BE one of the roles assumed by the node during processing of the message [ref to section 2.6]." as this seems to go beyond the bounds of an editorial change.[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP WG has decided to close issue 215 with the following resolution: Your text for 5.4.4 has been accepted with a slight modification. The first sentence of the section beginning "The Role element information..." was changed to: "The value of the Role element information item identifies a role the node was playing at the point the fault occurred. This MUST be one of the roles assumed by the node during processing of the message (see 2.2 SOAP Roles and SOAP Nodes)." Second sentence is actually at the end of the section and reads: "The value of the Role element information item MUST be one of the roles assumed by the node during processing of the message (see 2.2 SOAP Roles and SOAP Nodes)."[email, email] |
|||||||
216 | spec | n/a | meta | Design | Closed | Noah Mendelsohn | |
Title: Make the security considerations clearer | |||||||
Description:
Section 7: I find this section to generally be in need of editing to tighten the wording and to make the messages clearer. I would still prefer to put it in an appendix, as almost none of the rules in it are testable or can be directly used to distinguish a conforming from a non-conforming implementation.[email] |
|||||||
Proposal: | |||||||
Resolution:
The WG discussed this issue on 10th July and decided to close it without incorporating any of the suggested revisions.[email] |
|||||||
217 | spec | n/a | meta | Design | Closed | Stuart Williams | |
Title: (Relative or not?) URI identifying a SOAP node | |||||||
Description:
(Section 2.1 SOAP Nodes) A SOAP node MUST be identified by a URI. Wonder if we should say "unambigously identified". eg. http://.../next does not unambiguously identify a SOAP node (some context for interpretation is required in addition to a URI in order to identify a SOAP node from this URI). Can the URI be relative? I think not! Should we say "absolute URI"? Good points. Another question: why 'MUST' a SOAP node be identified by a URI ? Roles are identified by a URI, but why must a SOAP node be ? Should this be a 'MAY' ?[email] |
|||||||
Proposal: | |||||||
Resolution:
During the XMLP-WG telcon on 17th July 2002 the XMLP-WG resolved to close issue 217 as proposed by Marc Hadley in [2]: Proposal ======== I think Stuart pretty much nailed it above. Identifying a node is optional, but when a node *is* identified a URI is used. Suggest we change "A SOAP node MUST be identified by a URI." to "A SOAP node is identified by an unambiguous URI".[email] |
|||||||
218 | spec | n/a | meta | Design | Closed | Stuart Williams | |
Title: Active intermediaries specification | |||||||
Description:
(Section 2.7.2 Active Intermediaries) One mechanism by which an active intermediary can describe the modifications performed on a message is by inserting header blocks into the outbound SOAP message. These header blocks can inform downstream SOAP nodes acting in roles whose correct operation depends on receiving such notification. In this case, the semantics of such inserted header blocks should also call for either the same or other header blocks to be (re)inserted at subsequent intermediaries as necessary to ensure that the message can be safely processed by nodes yet further downstream. For example, if a message with header blocks removed for encryption passes through a second intermediary (without the original header blocks being decrypted and reconstructed), then indication that the encryption has occurred must be retained in the second relayed message. Personnally I'd delete this paragraph... it feels a little arm-wavey. It certainly specifies nothing and is largely tutorial.. if that.[email] |
|||||||
Proposal: | |||||||
Resolution:
At its telcon today (after you left), the XMLP WG decided to close Last Call issue #218 [1] by removing the paragraph to which you objected to the Primer.[email] |
|||||||
219 | spec | n/a | meta | Design | Closed | Stuart Williams | |
Title: Definition of a SOAP module | |||||||
Description:
(Section 3.1 SOAP Features) 3rd Paragraph - last sentence: A feature expressed as SOAP headers is known as a SOAP module, and each module should be specified according to the rules in 3.2 SOAP Modules. Personnally, I would like a really strong model of features, properties, modules, bindings and expressions. "A feature expressed as SOAP headers is known as a SOAP module..." just does not do it for me. Features are abstract things (given the examples). Modules are specifications of concrete behaviours and message components that realise the functionality of one (or more) features. In the case of modules the syntactic message components (feature related properties (state) ?) are expressed within SOAP headers. But... SOAP modules are not, not, not a kind of feature (that's what the quoted sentence says if you drop out the qualification). On the whole I don't think we articulate the concepts of features, properties, modules and bindings with any rigourous clarity - we need to do that.[email] |
|||||||
Proposal: | |||||||
Resolution:
On July 31st, the WG agreed to close issue #219 as follows: Replace the sentence in section 3.1 beginning with "A feature expressed as SOAP headers..." with the following: "When a feature is expressed this way, the combined syntax and semantics of such headers are known as a SOAP Module, and are specified according to the rules in section 3.2 SOAP Modules." Then replace the first two sentences of 3.2 with: "The term 'SOAP Module' refers to the set of syntax and semantics associated with implementing a particular feature (link to 3.1) as SOAP headers. A Module is described in a Module Specification, which adheres to the following rules. It:" Further, we agreed to insert the following as the new second rule in section 3.2, moving the other rules down one: "2. MUST, *if* the Module implements a Feature which has already been defined elsewhere, clearly refer to said Feature's URI. Note that a Module may EITHER explicitly refer to a separate Feature in this way OR may implicitly define a Feature simply by describing the semantics of the Module." (note that this last bit relies on a Feature having a URI, which is dealt with by the resolution of issue #230 [2])[email] |
|||||||
220 | spec | n/a | Binding | Design | Closed | Stuart Williams | |
Title: Remove contradiction on SOAP binding definition | |||||||
Description:
(3.1 SOAP Features) Last paragraph: A binding specification that expresses such features external to the SOAP envelope should define its own processing rules to which a SOAP node is expected to conform (for example, describing what information must be passed along with the SOAP message as it leaves the intermediary). seems contradictory with (from 4. SOAP protocol binding framework): A binding does not provide a separate processing model and does not constitute a SOAP node by itself. Rather a SOAP binding is an integral part of a SOAP node (see 2. SOAP Processing Model). The first says that a binding does provide a model for processing features external to the envelope. The second says more globally that a binding does not provide a separate processing model. If there are subtle distinctions here then we MUST find ways to remove the subtelty from the language. IMO a spec has *no* business being subtle... it only leads to trouble later.[email] |
|||||||
Proposal: | |||||||
Resolution:
At the f2f the WG decided to close issue 220 you raised by changing the text in Part 1, section 3.1, last paragraph (based on the email exchange between you and Noah [3]): <originalText> A binding specification that expresses such features external to the SOAP envelope needs to define its own processing rules to which a SOAP node is expected to conform (for example, describing what information is passed along with the SOAP message as it leaves the intermediary). It is recommended that, where practical, end-to-end features be expressed as SOAP header blocks, so that the rules defined by the SOAP Processing Model can be employed. </originalText> <newText> A binding specification that expresses such features external to the SOAP envelope needs to define its own processing rules for those externally expressed features. A SOAP node is expected to conform to these processing rules (for example, describing what information is passed along with the SOAP message as it leaves the intermediary). The processing of SOAP envelopes in accordance with the 2. SOAP Processing Model MUST NOT be overridden by binding specifications. </newText>[email] |
|||||||
221 | spec | n/a | meta | Design | Closed | Stuart Williams | |
Title: Clarify whether intermediaries forward Processing Instructions | |||||||
Description:
(Section 5 SOAP Message Construct) 3rd paragraph: We are not clear about whether intermediaries MUST, SHOULD, MAY, SHOULD NOT or MUST NOT forward PIs - only that a message SHOULD NOT contain them.[email] |
|||||||
Proposal: | |||||||
Resolution:
At the SOAP WG Telcon of September 4th, the WG agreed to close issue 221 by adopting the text: "Except in the special case of intermediaries (see below), envelopes transmitted by SOAP senders MUST NOT contain PIs. Receivers (including intermediaries) receiving an envelope with a PI SHOULD fault with a sender fault. However, in the case where performance considerations make it impractical for an intermediary to detect PIs in a message to be relayed, such intermediaries MAY leave the PIs unchanged in the relayed message."[email,email] |
|||||||
222 | spec | n/a | Encoding | Design | Closed | Stuart Williams | |
Title: Single instance of encodingStyle attribute (scope?) | |||||||
Description:
(Section 5.1.1 SOAP encodingStyle Attribute) 1st paragraph: SOAP defines an optional encodingStyle attribute information item which indicates the encoding rules used to serialize a SOAP message. This sentence suggest that a single instance of the attribute applies to the whole message... which I believe is not the case. I'm also not sure how we resolved whether the attribute can be carried on the envelope itself or not.[email] |
|||||||
Proposal: | |||||||
Resolution:
It was noted during the WG call, July 10, that the latest Last Call specification text clarifies the scope of the encodingStyle attribute as stated below: First sentence of 5.1.1 now reads: The encodingStyle attribute information item indicates the encoding rules used to serialize parts of a SOAP message. Additionally, later in the section one finds: 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. If no encodingStyle attribute information item is in scope for a particular element information item or the value of such an attribute information item is the zero-length URI ("") then no claims are made regarding the encoding style of that element information item and its descendants.[email] |
|||||||
223 | spec | n/a | Binding | Design | Closed | Noah Mendelsohn | |
Title: Use of optional HTTP Features | |||||||
Description:
Tables 9 [1] and 16 [2] of the latest editors drafts of SOAP 1.2 contain entries such as: ----------------+-------------------------------------------------------- Additional | Generated in accordance with the rules for the binding | specific expression of any optional features Headers | in use for this message exchange ----------------+-------------------------------------------------------- IBM is pleased to see these entries but requests that consideration be given to adding a clarification during last call. Specifically, IBM requests that a note be added to make clear that features such as http Content-Encoding [3] may be enabled through use of the features described in the table entry above. IBM would like for content-encoding to be supported when using SOAP over HTTP, and we believe that the current draft does support it. We are only requesting that the spec be made a bit clearer on this point. Thank you very much.[email] |
|||||||
Proposal: | |||||||
Resolution:
In response to issue, we are augmenting the text in Value of the Addt'l Headers row in Tables 15 [2] and 22 [3] in Part 2 of the SOAP spec. "Generated in accordance with the rules for the binding specific expression of any optional features in use for this message exchange. For example, a content-encoding header [4] may be used to express an optional Compression feature."[email] |
|||||||
224 | spec | n/a | Binding | Design | Closed | Henrik Frystyk Nielsen | |
Title: HTTP status codes | |||||||
Description:
From [2], this should be added to section 7.4.1.2 [4]: Table 11 refers to some but not all of the existing HTTP/1.1 status codes (see RFC 2616). In addition to these status codes, HTTP provides an open-ended mechanism for supporting status codes defined by HTTP extensions (see RFC 2817 for a registration mechanism for new status codes). HTTP status codes are divided into status code classes as described in RFC 2616, section 6.1.1. The SOAP HTTP binding follows the rules of any HTTP application which means that an implementation of the SOAP HTTP binding must understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response must not be cached.[email] |
|||||||
Proposal: | |||||||
Resolution:
During the XMLP telcon on July 10th, the XMLP working group accepted Henrik Nielsen's suggested text listed in LC-Issue #224 [1]. The editors have taken an action item to add this to section 7.5.1.2 "Requesting" near Table #17, effectively closing this issue.[email] |
|||||||
225 | spec | n/a | meta | Design | Closed | Henrik Frystyk Nielsen | |
Title: SOAP processing model | |||||||
Description:
From [1], this should replace the 2nd paragraph in section 2 [3]: This section defines the SOAP distributed processing model. The SOAP processing model specifies how a SOAP receiver processes a SOAP message. It applies to a single message only, in isolation from any other SOAP message. The SOAP processing model itself does not maintain any state or perform any correlation or coordination between messages, even, for example, when used in combination with a feature which involves sending multiple SOAP messages in sequence, each subsequent message depending on the response to the previous message. It is the responsibility of each such features to define such combined processing. Section 4. SOAP Protocol Binding Framework defines a framework for describing the rules for how SOAP messages can be exchanged over a variety of underlying protocols. Section 3. SOAP Extensibility Model describes how SOAP can be extended and how SOAP extensions might interact with the SOAP processing model and the SOAP protocol binding framework.[email] |
|||||||
Proposal: | |||||||
Resolution:
The XML WG has decided to close issue 225 with the text you suggested. It considers this issue is editorial in nature.[email] |
|||||||
226 | spec | n/a | meta | Design | Closed | Paul Prescod | |
Title: What does WS URI address? | |||||||
Description:
Most existing Web services set up namespaces in competition with that of the Web (URIs). They do this because they use a single URI for the "service" and then use proprietary identifiers within. For instance UDDI uses UUIDs, .NET My Services uses Passport User IDs and XPaths and so forth. Others use RPC to set up a parameterized n-tuple as an addressing mechanism. The problems with this are well-documented, but the tools do not really support a URI-centric mode of operation and (I fear) will not unless the specification makes clear that they are mistaken.[email] |
|||||||
Proposal:
I believe that the SOAP specification (or at least primer) should address this issue directly. Here is what I propose (based in parton some terminological suggestions by Noah Mendelsohn): """One of the principles of Web Architecture is that all important resources should be identified by URIs. This implies that most well-architected SOAP services will be embodied as large numbers or resources, each with its own URI. Indeed, many such resources are likely to be created dynamically during operation of the service, as new information becomes available. For example, a service allowing airline tickets to be ordered would have different URIs for each order. As new orders come in, they would be given URIs and SOAP requests would be directed at those URIs, not at a single monolithic "service" URI.""" |
|||||||
Resolution:
"... The problems with this are well-documented, but the tools do not really support a URI-centric mode of operation and (I fear) will not unless the specification makes clear that they are mistaken. ..." We propose to close this issue without further changes to the specs because: 1. Details of URI encoding are out-of-scope of the Normative parts of SOAP 1.2 [6], 2. The Primer provides non-normative discussion in section 3.1.3 [3], which appears to address your concern, 3. Part 2 also seems to address your concern [7], and 4. The Web Services Architecture or Description WGs may be more receptive of further work on this issue Also see [4], where it looks like the TAG had an action to ask WSAWG to address this (or a very similar) concern. From the IRC log of that TAG call [5], 20:05:26 [Ian] Action DC: Write up architecture concern. More recently, looks like the TAG may be working through the WSDWG [8][9]. WSD WG has it as issue #61 [10].[email] |
|||||||
227 | spec | n/a | Binding | Design | Closed | Stuart Williams | |
Title: Web Method Feature | |||||||
Description:
Part 2 Table 15 [1] in the HTTP binding specification states that the HTTP Method is set "According to the webmeth:Method property (typically POST or GET)." This implies that correct operation of the HTTP binding *requires* the *use* of the Web Method feature rather than merely the provision of the feature by implimentations of the binding. I take the MUST in [2] to be a statement about the provision rather than the use of the Web Method feature. IMO it should be possible to use either of the Request-Response or SOAP-Response MEPs without knowledge of the Web Method feature and that in such circumstances the HTTP Method used should be POST and GET respectively. This latter is behaviour is in line with the norm described in the narrative in the final paragraph of part 2 section 6.4.3 [3] but is not evident as default behaviour in the HTTP binding description. </Comment> See also issue 228.[email] |
|||||||
Proposal:
Suggested Remedy ---------------- In the first row of Part 2 Table 15 [1], replace "According to the webmeth:Method property (typically POST or GET)." with "When the webmeth:Method property is present in the Message Exchange Context, HTTP Method is set according to the value of the webmeth:Method property (typically POST or GET). Otherwise, the HTTP methods used is POST if the message exchange pattern in use is the 6.2 Request-Response Message Exchange Pattern ie. context:ExchangePatternName is set to http://www.w3.org/2002/06/soap/mep/request-response/ or the GET if the message exchange pattern is 6.3 SOAP Response Message Exchange Pattern ie. context:ExchangePatternName is set to http://www.w3.org/2002/06/soap/mep/SOAP-response/." More compact wording to similar effect or tabular presentation would be acceptable. eg for the first row of Table 15: ============+=========================+================================= HTTP Method |webmeth:Method used | Set according to webmeth:Method +-------------------------+--------------------------------- |Request-Response MEP & | HTTP POST |(webmeth:Method not-used)| +-------------------------+--------------------------------- |SOAP-Response MEP & | HTTP GET |(webmeth:Method not-used)| ============+=========================+================================== |
|||||||
Resolution:
At it's face to face meeting in Palo Alto (July 31 - Aug 2, 2002), the workgroup agreed to the following resolution of issue 227: * A binding specification MAY require that certain "feature(s)" be used in particular situations when using the binding. In other words, the binding specification may decline to provide any means of operation when such feature is not used. * Whether use of a feature is optional or mandatory (in the sense described above), a feature must always be used correctly when used. In other words, the use by the binding specification must be consistent with the specification for the feature itself. * Issue 227 in particular questions such mandatory use of the webMethod feature by the HTTP binding. The WG has voted to make no change in this mandatory use of the webMethod feature by the http binding. The HTTP binding continues to mandate that a sending node determine the webMethod (e.g. POST, GET) to be used when transmitting a non-Response message. (Note that the entire property-based binding framework is abstract: at no point does the HTTP binding attempt to describe a particular API or implementation structure, so this resolution says nothing about whether method names such as GET would be supplied explicitly or otherwise on some particular API; it merely mandates that the sending node determine the method in some implementation specific manner, and it declines to supply any standard way of inferring the method from other information provided with the message to be transmitted.[email,email] |
|||||||
228 | spec | n/a | Binding | Design | Closed | Stuart Williams | |
Title: Be more explicit about the Web Method values that may be used with particular MEPs | |||||||
Description:
A related issue to issue 227 is that despite the sentence at [4], the paragraph at [3] does not give full account of the usage of the Web Method feature in combination with either the Request-Response or SOAP-Response MEPs for example which if any of the following are allowed/disallowed: a) MEP=Request-Response, webmeth:Method=GET b) MEP=Request-Response, webmeth:Method=DELETE c) MEP=SOAP-Response, webmeth:Method=POST d) MEP=SOAP-Response, webmeth:Method=PUT e) MEP=SOAP-Response, webmeth:Method=DELETE Such "unusual" use is discouraged in [3] but to comply with [4] the spec should be more explicit about the Web Method values that may be used with particular MEPs, ie. PUT and POST with Request-Response and GET (any others?) with SOAP-Response. Preconditions about the 'legal' combinations of MEP and Method could be expressed in the Web Method feature description.[email] |
|||||||
Proposal: | |||||||
Resolution:
During the last f2f, the WG came up with this decision to close issue 228: << Replace last paragraph of [2] with "Bindings implementing this feature MUST employee a Message Exchange Pattern with semantics that are compatible with the web method selected. For example, the (link to response only) pattern is compatible with GET. >>[email] |
|||||||
229 | spec | n/a | meta | Design | Closed | Hugo Haas | |
Title: Clarify "non-mandatory" in Processing SOAP Messages section | |||||||
Description:
Section 2.6 Processing SOAP Messages [1] of SOAP Version 1.2 Part 1: Messaging Framework [2] reads: | 4. Process all header blocks targeted at the node and, in the case of | an ultimate SOAP receiver, the SOAP body. A SOAP node MUST process | all SOAP header blocks targeted at it. A SOAP node MAY choose to | ignore the application level processing specified by non-mandatory | SOAP header blocks targeted at it. The last two sentences seem contradictory. A SOAP node: - MUST process all SOAP header blocks targeted at it. - MAY choose to ignore the application level processing specified by non-mandatory SOAP header blocks targeted at it. An old version of this text used to say [3]: | 2. Process SOAP blocks targeted at the SOAP node, generating SOAP | faults (see 4.4 SOAP Fault) if necessary. A SOAP node MUST process | SOAP blocks identified as mandatory. A SOAP node MAY process or | ignore SOAP blocks not so identified. This seemed to make more sense; a SOAP node: - MUST process all SOAP header blocks targeted at it that are identified as mandatory. - MAY process or ignore SOAP blocks targeted at it that are not marked as mandatory. Or maybe there is a subtle difference between "application level processing" and "processing" that I missed.[email] |
|||||||
Proposal: | |||||||
Resolution:
Issue 229, which you raised, was discussed by the XMLP WG and the resolution suggested in [2] was adopted.[email] |
|||||||
230 | spec | n/a | meta | Design | Closed | Glen Daniels | |
Title: Definition of features | |||||||
Description:
I note upon looking over the latest draft that although issue 203 [1] has been closed with the proposed text describing the rules about module specifications, there is still a slight problem that I'd like to clean up (after last call - so you can consider this the first item on the LC-feedback queue! :)). In the "requirements for features" section (3.1.1), we do not actually note that features should be associated with a URI in their specification. I think this would be a good thing to add. It would make it easier for the authors of binding and module specifications to refer to implemented features, and there may well be call to indicate in descriptions or negotiation protocols that a particular feature is used/referenced/required without specifying a particular implementation of that feature. Also, it would make it easier to talk about features with RDF models.[email] |
|||||||
Proposal:
Concrete proposal: In section 3.1.1 of part 1, move all the other items down, and insert a new item #1: 1. A URI used to refer to the feature. |
|||||||
Resolution:
On July 31st, the WG agreed to close issue #230 as follows: In section 3.1.1 of part 1, move all the other items down, and insert a new item #1: 1. A URI used to refer to the feature. This enables the feature to be unambiguously referenced in description languages or during negotiation.[email] |
|||||||
231 | spec | n/a | Encoding | Design | Closed | Marc Hadley | |
Title: What is the difference between a "struct" and an "array" in the edge case? | |||||||
Description:
> I believe that since in array the names are irrelevant, we must > not assume that they are the same. The name may be used for type > matching (if using some schema validation as suggested in > http://www.w3.org/TR/soap12-part2/#encschema ) or it may be > generated or (usually) it can be the same (like 'item' or > something) but the latter is just one of the options. Hmmm, thats not my reading of it. The rules in [1] are: "1. For a graph edge which is distinguished by label ("struct" or "generic"), the namespace name and local name properties of the element information item together determine the value of the edge label. 2. For a graph edge which is distinguished by position ("array" or "generic"): * The ordinal position of the graph edge corresponds to the position of the element information item relative to its siblings * If outbound edges are distinguished only by position ("array") then the local name and namespace name properties of the element information item are not significant." If the names of the child elements are not the same then the outbound edges are NOT distinguished only by position (see 2, bullet 2 above) and hence you have a generic rather than an array. I agree that the actual names of the array elements are not significant (although, as Jacek notes, they can be used for type matching) but they should all be the same.[email] |
|||||||
Proposal: email, email | |||||||
Resolution:
At the SOAP WG Telcon of October 9th, the WG agreed to close issue 231 by adopting the text proposed in http://lists.w3.org/Archives/Public/xml-dist-app/2002Sep/0193.html. The WG voted to adopt the attribute name of nodeType for use within the proposal text. The subissue of 231 was also closed by agreeing to the text in http://lists.w3.org/Archives/Public/xml-dist-app/2002Sep/0192.html.[email] |
|||||||
232 | spec | n/a | meta | Design | Closed | Hugo Haas | |
Title: Changing the default value of mustUnderstand to "true" | |||||||
Description:
Having a header block without mustUnderstand set to "true" allows the SOAP node supposed to process this block to ignore it as shown in 2.7.1 Forwarding Intermediaries [2],: | Forwarding intermediaries MUST process the message according to the | SOAP processing model defined in 2.6 Processing SOAP Messages. They | MUST also remove from the message all SOAP header blocks targeted at | themselves, prior to forwarding, regardless of whether these header | blocks were processed or ignored. and in 2.6 Processing SOAP Messages [3]: | 4. Process all header blocks targeted at the node and, in the case of | an ultimate SOAP receiver, the SOAP body. A SOAP node MUST process | all SOAP header blocks targeted at it. A SOAP node MAY choose to | ignore the application level processing specified by non-mandatory | SOAP header blocks targeted at it. The probability that somebody included a header and really wants something to happen as a result of its processing is high. The probability that the person doesn't care if the header is ignored is low. For example, every header block used as examples in the primer [4] (that I saw) uses env:mustUnderstand="true". It therefore seems natural to make "true" the default value for mustUnderstand.[email] |
|||||||
Proposal: | |||||||
Resolution:
The XML Protocol (XMLP) WG has decided to close issue 232, which you originated, with the following resolution. The XMLP WG has decided to close this issue without any change to the default value of the mustUnderstand attribute. It was felt that this change would be inconsistent with the current design and would cause mass confusion in the migration from SOAP 1.1 to SOAP 1.2.[email] |
|||||||
233 | spec | n/a | meta | Design | Closed | Henrik Frystyk Nielsen | |
Title: Conflict between empty role value and SOAP 1.2's use of xml:base | |||||||
Description:
From [1] it says: "Omitting the SOAP role attribute information item is equivalent to supplying that attribute with a value of "http://www.w3.org/2002/06/soap-envelope/role/ultimateReceiver". An empty value for this attribute is equivalent to omitting the attribute completely, i.e. targeting the SOAP header block at an ultimate SOAP receiver." However, "" is a value relative URI and so this statement conflicts with our use of xml:base [2] and our use of relative URIs: "URIs used as values in information items identified by the "http://www.w3.org/2002/06/soap-envelope" and "http://www.w3.org/2002/06/soap-encoding" XML namespaces can be either relative or absolute."[email] |
|||||||
Proposal:
Proposed resolution: Remove the last sentence in the above paragraph so that it reads: "Omitting the SOAP role attribute information item is equivalent to supplying that attribute with a value of "http://www.w3.org/2002/06/soap-envelope/role/ultimateReceiver"." |
|||||||
Resolution:
During the F2F, the WG has decided to close issue 233 by accepting your proposal: Remove the last sentence in the paragraph.[email] |
|||||||
234 | spec | n/a | Encoding | Design | Closed | Hugo Haas | |
Title: Change maximum arraySize value to "unbounded" | |||||||
Description:
Part 2, section 3.1.6 arraySize Attribute Information Item [1] reads: | The array's dimensions are represented by each item in the list of | sizes (unspecified size in case of the asterisk). This reminds me of the XML Schema maxOccurs attribute which specifies how many maximum times an element occurs [3]. maxOccurs unbounded value used to be "*" and was changed into "unbounded" by the XML Schema Working Group (see issue 221 [2]). For alignment purposes, I think that SOAP should also use "unbounded". Should the XML Schema Working Group define an array type, they would most certainly go with "unbounded".[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP WG has decided to close its last call issue #234 keeping the status quo. The rationale is provided in the thread starting with Gudge's proposal [2].[email] |
|||||||
235 | test collection | n/a | Editorial | Design | Closed | Anish Karmarkar | |
Title: Assertion and Test Collection doc: missing assertion | |||||||
Description:
This email is to point out an assertion in SOAP 1.2 Part 1 [1] which is not listed in the Assertion and Test Collection [2] document. The assertion occurs in section 5.4.3. The assertion text is: The type of the Node element information item is anyURI in the "http://www.w3.org/2001/XMLSchema" namespace.[email] |
|||||||
Proposal: | |||||||
Resolution:
Issue 235 has been closed by adding the missing assertion in the SOAP 1.2 Assertions and Test Collection document.[email] |
|||||||
236 | spec | n/a | Editorial | Design | Closed | Anish Karmarkar | |
Title: SOAP 1.2 Part 1 section 1.2 Editorial nit | |||||||
Description:
There is typo in SOAP 1.2 Part 1 section 1.2. "The SOAP envelope has the namespace name ..." should be "The SOAP Envelope has the namespace name ..." The complete paragraph is: Some of the information items defined by this document are identified using XML namespace [7] names (see 5. SOAP Message Construct). In particular, this document defines the following namespace names: * The SOAP envelope has the namespace name "http://www.w3.org/2002/06/soap-envelope" (see 5. SOAP Message Construct). * The SOAP Misunderstood element information item has the namespace name "http://www.w3.org/2002/06/soap-faults" (see 5.4.8 SOAP mustUnderstand Faults). * The SOAP Upgrade element information item has the namespace name "http://www.w3.org/2002/06/soap-upgrade" (see 5.4.7 VersionMismatch Faults).[email] |
|||||||
Proposal: | |||||||
Resolution:
The editors have resolved the issue by removing the duplication of the namespace information. The changes can be seen in the editors copy [3] ( deleted text is struckout and highlighted in red )[email] |
|||||||
237 | test collection | n/a | Editorial | Design | Closed | Anish Karmarkar | |
Title: SOAP 1.2 Assertions and Test Collection: Editorial | |||||||
Description:
Assertion 70, "Text from the specification" in [1] does not cut-and-paste correctly from the SOAP 1.2 Part 1 [2]. There is a missing a bullet: " Any number of character information item children. Child character information items whose character code is amongst the whitespace characters as defined by [8] are considered significant."[email] |
|||||||
Proposal: | |||||||
Resolution:
Issue 237 has been closed by fixing the 'cut-and-paste' error. The SOAP 1.2 Assertions and Test Collection document has been updated accordingly.[email] |
|||||||
238 | spec | n/a | Editorial | Design | Closed | Ajay Dubey | |
Title: SOAP Version 1.2 Part 0: Editorial | |||||||
Description:
Example 4: Element <m:reservation.........................> has got env:mustUnderstand="true" attribute defined. This element appears in the <env:body..........> of the SOAP message. The primer further says that mustUnderstand attribute is not allowed in the body. It is only allowed in header blocks. Is this a mistake?[email] |
|||||||
Proposal: | |||||||
Resolution:
Thanks for pointing this out (see excerpt below). It was a cut-and-paste mistake, and will be removed from the next revision of the SOAP 1.2 Primer WD. BTW, in the same element that you mention, the "role" attribute is also undefined for a body element, and should also be removed.[email] |
|||||||
239 | spec | n/a | Editorial | Design | Closed | Michael Mahan | |
Title: SOAP Version 1.2 Part 2: Editorial | |||||||
Description:
In Paragraph 6.3.3, (SOAP Response MEP), the text after Table 12 ('Bindings that...') is identical to the text after Table 7. This text needs updating - it refers to a SOAP request which is not part of the SOAP Response MEP (only the response is SOAP, the request is an HTTP GET without SOAP envelope, i.e. SOAP-free).[email] |
|||||||
Proposal: | |||||||
Resolution:
Thanks for spotting this. I think this is a cut-and-paste problem and that this text should be removed from the SOAP response section entirely.[email] |
|||||||
240 | spec | n/a | meta | Design | Closed | Lorrie Cranor | |
Title: comments from P3P Specification working group | |||||||
Description:
In section 5.2 of the Requirements document [1] it states "It must be possible to associate a P3P Privacy Policy with an XMLP message." In a previous exchange with the P3P Specification working group [2] we agreed that indeed it appeared that this was possible. However, we do not believe that the requirement can be adequately met without actually documenting how a P3P policy can be associated with an XMLP message. As there are a variety of ways this might be done, it is important that your working group document the preferred method so that implementations will be interoperable. In our previous discussion [2] it was suggested that a SOAP header could be defined to associate a policy with a message. (Actually it might make more sense to associate a policy reference file with a message if there is a way to uniquely reference messages by URI -- that's a topic we would be happy to discuss with you further). As far as we can tell, no such header has been defined. Furthermore it was suggested that a policy could be directly embedded within a header. If this mechanism is to be used, it would need to be documented that embedding a P3P policy has the meaning of associating that policy with the message within which it is embedded. There may be some scoping and lifetime issues that would also be necessary to resolve, as well as issues about resolving potential policy conflicts. When XMLP messages are conveyed over HTTP the existing mechanisms defined in the P3P1.0 specification may be used to associate policies with XMLP messages. However, it is unclear to us whether the P3P specification supplies a sufficient level of granularity to identify XMLP messages. If it does not, it is likely that the P3P extension mechanism could be used to provide this granularity, but again this would need to be documented. Furthermore, if other mechanisms are defined specifically for use with XMLP, then conflicts may arise between these mechanisms and the P3P1.0-defined mechanisms. The proper way to resolve these conflicts needs to be documented as well. Besides documenting how a P3P policy should be associated with an XMLP message, we believe it would be useful to offer some usage scenarios that include P3P. We are concerned that in the absence of discussion of privacy and P3P, developers will be likely to ignore privacy issues when implementing the XML Protocol. 1. http://www.w3.org/TR/2002/WD-xmlp-reqs-20020626 2. http://lists.w3.org/Archives/Public/xmlp-comments/2002Jan/0022.html[email] |
|||||||
Proposal: | |||||||
Resolution:
The XML Protocol (XMLP) WG has decided to close issue 240, which you originated, with the following resolution. The XMLP WG respectfully disagrees that the XMLP WG must document how P3P policies should be associated with XMLP messages in order to satisfy the requirement that it be possible "to associate a P3P Privacy Policy with an XMLP message". We believe the requirement is met through our previous agreement that in principle it is possible to associate P3P Privacy Policies with XMLP messages. The XMLP WG's charter explicitly states that its mission is to provide a framework that can support a wide variety of applications, but its mission explicitly excludes defining the semantics associated with particular applications. The XMLP WG does recognize the importance of Privacy, and it suggests sending the question of which other WG takes on this task to the Web Services Co-Ordination Group for consideration.[email] |
|||||||
241 | spec | n/a | meta | Design | Closed | Joseph Reagle | |
Title: detaching and inserting XML in one document from another (encryption issue) | |||||||
Description:
# SOAP Version 1.2 Usage Scenarios # W3C Working Draft 26 June 2002 # This version: # http://www.w3.org/TR/2002/WD-xmlp-scenarios-20020626 # 2.6 S6 Request with encrypted payload # # 2.6.1 Scenario Definition # # A sender wishes to exchange data with a receiver and has agreed to # encrypt the payload. The sending and receiving applications agree on # the encryption methodology. Data is encrypted by the originating # application and sent to the receiver via SOAP. The data reaches the # receiving application untouched, and may then be decrypted in the # agreed-upon manner. The *most* problematic issue for Signatures and Encryption are those related to detaching and inserting XML in one document from another. Simply, XML was not designed to do this well, and in many circumstances its not possible to do it well. Consequently, I believe that applications that do this need to be very clear about the methods of removal/insertion and SOAP seems an obvious example of this. I'd think the WG should consider either defining a mechanism of attachment/detachment (and the related Infoset clean up) or contrain/warn applications as xmldsig [1] and xenc [2] have done about the use of xmlns="", and xml:foo attributes, and using qualified names in attribute values -- or at least quickly repeat/reference those arnings.[email] |
|||||||
Proposal: | |||||||
Resolution:
At the F2F, the XMLP discussed issue 241 you raised. After hearing your clarifications, the WG has decided to close this issue without changes in the specification.[email] |
|||||||
242 | spec | n/a | meta | Design | Closed | Joseph Reagle | |
Title: Editorial: SOAP Version 1.2 Part 0: Primer - about implementations | |||||||
Description:
# Following completion of Last Call, the XML Protocol Working Group has # agreed to advance the specification according to four exit criteria: # 1. Sufficient reports of implementation experience have been gathered # to demonstrate that SOAP processors based on the specification are # implementable and have compatible behavior. What does this mean in the context of the primer and scenarios? Will you want to see evidence of all the scenarios having been accomplished before you advance the specifications?[email] |
|||||||
Proposal: | |||||||
Resolution:
The XML Protocol (XMLP) WG has decided to close issue 242, which you originated, with the following resolution. The XMLP WG intends to collect implementation experience regarding the features present in Parts 1 and 2 of the SOAP specification only. The appearance of the "4 exit criteria" statement in Last Call documents other than Parts 1 and 2 was a mistake, and was not intended to indicate that the WG would be collecting implementation experience based on other documents such as the Primer and Scenarios documents.[email] |
|||||||
243 | spec | n/a | meta | Design | Closed | Joseph Reagle | |
Title: SOAP Version 1.2 Part 0: Primer & part 1 - implementations | |||||||
Description:
# 2. An implementation report shows that there are at least two # different and interoperable implementations of every mandatory and # optional feature. My comment is more to Part 1, then this primer, but I also recommend a requirement of one COMPLETE implementation of all mandatory features: "Given different implementations, their variance in the 20% each fails to do well causes 80% of the users' headaches."[email] |
|||||||
Proposal: | |||||||
Resolution:
We believe the essence of your concern to be that we have committed to looking for implementations of each of the mandatory features of our specification, but not to one single implementation that embodies them all. We discussed your concern at some length at our face to face meeting in Palo Alto this week, and I think it's fair to say there is considerable sympathy for the spirit of the concern that you raise. So, we gave some thought to how this might reasonably be done. SOAP is a wire format, and the specification is quite intentionally written to not have any notion of a COMPLETE implementation. Just as a simple example, the mandatory responsibilities of a sender are different from those of a receiver, and there is no requirement that any one piece of software provide both capabilities. Also, the generation of certain faults is mandatory in the abstract, but where you deliver them depends on the (optional) message exchange pattern in use (for the request/response MEP, faults generated when processing a request are sent back to the requester, but faults generated in processing a response are generally known only to the node encountering the error...since we have way to get back to the responder.) A further example of an implementation that conforms to mandatory requirements but that fails to illustrate certain interesting behaviors: we expect that many embedded controllers will decline all header processing by merely claiming not to "understand" any (or most) headers. So, there is no notion of a COMPLETE implementation, and only a few truly mandatory requirements; there are of course mandatory requirements in most particular situations. That said, we do expect that certain sorts of implementations will be reasonably common. For example, we anticipate that many vendors will build relatively general purpose SOAP "servers" that serve as receivers for requests and as senders for responses. Taking all these considerations into account, the workgroup has decided that our formal criteria for exit from last call will not change, but that we will undertake a good faith effort to ensure that implementations exist that embody the anticipated common combinations of mandatory (and as apppropriate optional) features. We hope that you will find this approach to be appropriate.[email] |
|||||||
244 | spec | n/a | Editorial | Design | Closed | Joseph Reagle | |
Title: SOAP Version 1.2 Part 0: Primer - define method signature | |||||||
Description:
# Therefore, when a RPC definition is such that all the parts of its # method signature can be described as resource-identifying and hence Please define "method signature", this will be useful and also make it clear you are not speaking of a digital signature.[email] |
|||||||
Proposal: | |||||||
Resolution:
The expression "method signature" has been removed, and therefore does not need to be defined. Words such as "method description" are used where appropriate.[email] |
|||||||
245 | spec | n/a | Editorial | Design | Closed | Joseph Reagle | |
Title: SOAP Version 1.2 Part 0: Primer - exemple 5b | |||||||
Description:
# Example 5b # <rpc:result>m:status</rpc:result> # <m:status>confirmed</m:status> This is a very odd sort of construct. I know it's just an example, but is this sort of thing expected to be the norm, I would expect: <rpc:result><m:status>confirmed</m:status></rpc:result>[email] |
|||||||
Proposal: | |||||||
Resolution:
The Primer follows the main specifications in this formulation; so your issue is really an issue against the Parts 1, 2 specifications. A similar concern against the main specifications has been raised in Issue #299 [2]. Therefore, I intend to close this issue from the point of view of the Primer, and will revise the example only if the main specifications change as a part of the resolution of Issue 299.[email,email] |
|||||||
246 | spec | n/a | meta | Design | Closed | Joseph Reagle | |
Title: SOAP Version 1.2 Part 0: Primer - header and body definition | |||||||
Description:
# 2.3 Fault scenarios # The SOAP Body element has another distinguished role in that it is the # place where such fault information is placed. The SOAP fault model # (see Part 1, section 5.4) requires that all SOAP-specific and # application-specific faults be reported using a single distinguished # element, Fault, carried within the Body element. The Fault # element contains two mandatory sub-elements, Code and # Reason, and (optionally) application-specific information in the # Detail sub-element within the Fault. Another optional # sub-element, Node, identifies via a URI the SOAP node which # generated the fault, its absence implying that it was the ultimate # recipient of the message which did so. There is another optional # sub-element, Role, which identifies the role that the node which # generated the fault was playing. The various specifications repeatedly attempt to define the difference the header and the body, which I appreciate, but I'm still a little confused. I understand that header information is of interest on the hop (intermediaries) but the body is for the end-to-end (destination). But if I'm putting error messages in the body, couldn't it be possible that the intermediaries would be interested in that as well?[email] |
|||||||
Proposal: | |||||||
Resolution:
During the last f2f, the WG came up with the decision to close issue 246 you raised without further changes to the spec: Reason: There is nothing within the spec that prevents an intermediary from inspecting the error messages within the body. We recognise there is a potential problem with this, but it is not by itself significant enough to warrant another last call. If we decide to go back to last call we will reconsider the design for fault handling in body and/or headers.[email] |
|||||||
247 | spec | n/a | Editorial | Design | Closed | Joseph Reagle | |
Title: SOAP Version 1.2 Part 0: Primer - Editorial | |||||||
Description:
# Part 1 section 5.4 of the SOAP specifications describes the # structure of the fault message while the SOAP processing model defines I was briefly confused by these "Part 1" section foo, I kept thinking, Part 1 of what specification? I know it's stated in section 1, but perhaps on the first few instances in the text, you could include the full name.[email] |
|||||||
Proposal: | |||||||
Resolution:
This comment has been incorporated into the editor's copy of the Primer[email] |
|||||||
248 | spec | n/a | Editorial | Design | Closed | Joseph Reagle | |
Title: Editorial - Harmonizing example captions and descriptions | |||||||
Description:
# Example 12b In the Primer, an example has the "Example #" and a description below the example, Part 1 has the description at the top. These should be harmonized, I prefer it at the top.[email] |
|||||||
Proposal: | |||||||
Resolution:
We respectfully decline to make the proposed change, as this adds a lot of extra work without any real benefit. Moreover, the examples in the main specifications are not referenced elsewhere in the documents except in the immediate preceding text. The Primer makes frequent references to individual examples from various parts of the document, hence an additional row. Changing its position would not, in our opinion, add anything, and we do not feel that readers would be discommoded by its current placement.[email] |
|||||||
249 | spec | n/a | meta | Design | Closed | Joseph Reagle | |
Title: SOAP Version 1.2 Part 1: Messaging Framework | |||||||
Description:
# 1.2.2 Robustness Principle # # In some cases, the use of XML technologies allows the flexibility for # expressing semantically equivalent statements in a variety of # different ways. In order to obtain robust and interoperable # implementations it is essential that SOAP implementations take into # account the Robustness Principle as expressed by RFC 1123 # and RFC 793 : "Be liberal in what you accept, and # conservative in what you send". I know this can be a matter of debate, but I believe this principle has caused the majority of headaches of users of document formats: permitting innumerable cruddy instances which necessitate complex heuristic based parser/applications. While it is still in some limited protocol scenarios, I'm generally cautious towards it, and oppose it with to document syntaxes.[email] |
|||||||
Proposal: | |||||||
Resolution:
Regarding issue 249, we are moving section 1.2.2 from the specification.[email] |
|||||||
250 | spec | n/a | meta | Design | Closed | Joseph Reagle | |
Title: SOAP Version 1.2 Part 1 - definition of a role | |||||||
Description:
# 2.2 SOAP Roles and SOAP Nodes # This specification defines the following SOAP roles: # * "http://www.w3.org/2002/06/soap-envelope/role/next". Each SOAP # intermediary and the ultimate SOAP receiver MUST act in this role # and MAY additionally assume zero or more other SOAP roles. # * "http://www.w3.org/2002/06/soap-envelope/role/none". SOAP nodes # MUST NOT act in this role. # * "http://www.w3.org/2002/06/soap-envelope/role/ultimateReceiver". # To establish itself as an ultimate SOAP receiver a SOAP node MUST # act in this role. SOAP intermediaries MUST NOT act in this role. Where? If the intent is to define them here, it merely states if a SOAP node can act in the role, I really haven't found a good definition of these roles.[email,email] |
|||||||
Proposal: | |||||||
Resolution:
The relationship between a role and a role name is similar to that between a resource and a URI. The role name is just an identifier identifying the role. In fact, given that the role name is a URI, a role is therefore a resource. In the current text, I would tend to agree with you that it would be more appropriate to say that we define roles who have known URIs rather than saying that we define role names. Throughout the spec we talk about roles and not just their names. In response to your comment, would the editorial clarification below make the definition of roles easier to pinpoint? * * * * * This specification defines the following roles which have special significance in a SOAP message (see 2.6 Processing SOAP Messages): * The role identified by the URI "http://www.w3.org/2002/06/soap-envelope/role/next". Each SOAP intermediary and the ultimate SOAP receiver MUST act in this role and MAY additionally assume zero or more other SOAP roles. * The role identified by the URI "http://www.w3.org/2002/06/soap-envelope/role/none". SOAP nodes MUST NOT act in this role. * The role identified by the URI "http://www.w3.org/2002/06/soap-envelope/role/ultimateReceiver". To establish itself as an ultimate SOAP receiver a SOAP node MUST act in this role. SOAP intermediaries MUST NOT act in this role. In addition to those described above, other roles MAY be defined as necessary to meet the needs of SOAP applications. In addition to the three SOAP roles defined above, other roles MAY be defined as necessary to meet the needs of SOAP applications. * * * * *[email] |
|||||||
251 | spec | n/a | meta | Design | Closed | Joseph Reagle | |
Title: SOAP Version 1.2 Part 1 - Mandatory SOAP headers | |||||||
Description:
# 2.4 Understanding SOAP Headers # Mandatory SOAP header blocks are presumed to somehow modify the # semantics of other headers or body elements. This surprises me, I'd think I could have Mandatory SOAP headers that can co-exist, however on further thought this sounds like a good idea.[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP working group have closed Issue 251 by stating that it requires no action as it is a non-issue. If you disagree with this assessment of the issue please let the working group know as soon as possible.[email] |
|||||||
252 | spec | n/a | meta | Design | Closed | Joseph Reagle | |
Title: SOAP Version 1.2 Part 1 - SOAP Message Construct | |||||||
Description:
# 5. SOAP Message Construct # # The XML infoset of a SOAP message MUST NOT contain a document type # declaration information item. # # A SOAP message SHOULD NOT contain processing instruction information # items. A SOAP receiver MUST ignore processing instruction information # items in SOAP messages that it receives. I recommend you also make (or reference) further constraints on xml:foo and other issues I mentioned if it's likely that the payload will be detached/ -- unless you define methods of changing the Infoset in these ways.[email] |
|||||||
Proposal: | |||||||
Resolution:
The WG decided to close issue 252 as it is a duplicate of issue 241 [2] (that you also raised). |
|||||||
253 | spec | n/a | Editorial | Design | Closed | Joseph Reagle | |
Title: SOAP Version 1.2 Part 2 - URIs in SOAP | |||||||
Description:
# 6. Use of URIs in SOAP # # SOAP does not define a base URI but relies on the mechanisms defined # in XML Base and RFC 2396 for establishing a base # URI against which relative URIs can be made absolute. Again, use of base URIs across payload attach/detach boundaries should be constrained.[email,email] |
|||||||
Proposal: | |||||||
Resolution:
The editors have decided to resolve this issue by taking no action. SOAP does rely on XML base and RFC 2396 for dealing with relative URIs. The editors did not consider it necessary to say anything about payload boundaries in this specification.[email] |
|||||||
254 | spec | n/a | meta | Design | Closed | Joseph Reagle | |
Title: SOAP Version 1.2 Part 2 vs RDF datamodel | |||||||
Description:
# SOAP Version 1.2 Part 2: Adjuncts # W3C Working Draft 26 June 2002 # This version: # http://www.w3.org/TR/2002/WD-soap12-part2-20020626 # 3.1 Rules for Encoding Graphs in XML Would the RDF datamodel and serialization suffice in place of this?[email] |
|||||||
Proposal: | |||||||
Resolution:
The XML Protocol (XMLP) WG discussed and decided to close issue 254, which you originated, with the following resolution: SOAP encoding is optimized for various applications and has implementation standing in the community. We do not believe that RDF should replace SOAP encoding.[email] |
|||||||
255 | spec | n/a | Editorial | Design | Closed | Art Salwin | |
Title: SOAP Version 1.2 Part 0 - Clarify what the parameters are in examples 4 and 5 | |||||||
Description:
Example 4 is a SOAP RPC request with a mandatory header and two "in" parameters. However, it is not clear (or at least not clear to me) what the two "in" parameters are. Please explicitly call them out in the text. Also please explain what the "5" is in the header (one line before </t:transaction>). (Maybe it's one of the two parameters?) Example 5 is a RPC response with two "out" parameters. However, it is not clear what the two "out" parameters are. Please explicitly identify them in the text.[email] |
|||||||
Proposal: | |||||||
Resolution:
This comment has been incorporated into the editor's copy of the Primer[email] |
|||||||
256 | spec | n/a | Editorial | Design | Closed | Martin Duerst | |
Title: Printing on A4 paper | |||||||
Description:
When printing on A4 paper, many of the examples get cut off on the right. Examples should be reedited so that they are somewhat less wide and can be printed on paper around the world without loss.[email] |
|||||||
Proposal: | |||||||
Resolution:
I have printed Part 1 and Part 2 of the spec on A4 paper and all example print correctly. Hence no action has been taken.[email] |
|||||||
257 | spec | n/a | Editorial | Design | Closed | Martin Duerst | |
Title: Part 0 - Examples should be more international | |||||||
Description:
The examples should be changed to be more international. People travel all around the world, to places that have names with characters outside US-ASCII,... Web Services can easily take care of this, and this should be shown. (please ask your chair, who knows how to do this from the XML Schema primer :-)[email] |
|||||||
Proposal: | |||||||
Resolution:
Your editorial comment on the SOAP Part0: Primer, marked as Last Call Issue#257 has been accepted and handled in the latest editor's copy of the document. The passenger's name as well as fault texts have been "internationalized".[email] |
|||||||
258 | spec | n/a | Editorial | Design | Closed | Martin Duerst | |
Title: Part 0 - Explain why xml:lang is important | |||||||
Description:
Example 6: The use of xml:lang="en-US" is very good. A comment saying why xml:lang is important would be even better.[email] |
|||||||
Proposal: | |||||||
Resolution:
This comment has been incorporated into the editor's copy of the Primer[email] |
|||||||
259 | spec | n/a | Editorial | Design | Closed | Martin Duerst | |
Title: Part 0 - change x:date | |||||||
Description:
Example 8b: <x:date>12-14-01</x:date>: This is not interoperable! Please use either XML Schema dates (<x:date>2001-12-14</x:date>), because this is machine-to-machine communication, or something like <x:date xml:lang='en-US'>December 14, 2001</x:date> if this is intended for human viewers.[email] |
|||||||
Proposal: | |||||||
Resolution:
This comment has been incorporated into the editor's copy of the Primer[email] |
|||||||
260 | spec | n/a | Editorial | Design | Closed | Martin Duerst | |
Title: Part 0 - explain rules for charset with application/soap+xml | |||||||
Description:
Example 11: charset="utf-8": It would be a good chance to shortly explain the rules for the charset parameter with application/soap+xml (because otherwise, the reader has to follow two references). The best recommendation is probably: Don't use a 'charset' parameter on 'Content-Type', because then the rules for freestanding XML (UTF-8 and UTF-16 (the later always with BOM) as defauts, otherwise <?xml ... encoding='foo'...) apply.[email] |
|||||||
Proposal: | |||||||
Resolution:
This comment has been incorporated into the editor's copy of the Primer[email] |
|||||||
261 | spec | n/a | Editorial | Design | Closed | Martin Duerst | |
Title: Part 0 - choose character encoding UTF8/16 | |||||||
Description:
> 4.2: "A binding, if using XML 1.0... MAY mandate that a particular > character encoding or set of encodings be used." This is good, but should be changed to say that in such a case, UTF-8/UTF-16 should be choosen (in accordance with XML 1.0 and the Character Model).[email] |
|||||||
Proposal:
See Gudge's proposal and following thread. See Gudge's amended proposal and following thread. See Gudge's second amended proposal and following thread. |
|||||||
Resolution:
The editors have closed this issue with no change on the grounds that the requested change is already covered by the "application/soap+xml" media type registration [3] by reference to RFC3023 [4].[email] |
|||||||
262 | spec | n/a | Editorial | Design | Closed | Martin Duerst | |
Title: Part 0 - significant whitespace? | |||||||
Description:
5., last paragraph: This is written as if all white space is by default ignored. But it is probably meant to apply only to insignificant whitespace (e.g. between elements in element content).(See also 208) [email] |
|||||||
Proposal: See Gudge's proposal | |||||||
Resolution:
The language in the specification will be amended to make sure it is clear that only insignificant whitespace can be ignored.[email] |
|||||||
263 | spec | n/a | Editorial | Design | Closed | Martin Duerst | |
Title: Part 0 - comments on <reason> | |||||||
Description:
5.4.2: <reason>: xml:lang is optimal, but there should be a note saying that it is strongly recommended. <reason>: xml:lang is said to have a namespace name of "http://www.w3.org/XML/1998/namespace". This alone does not guarantee that the prefix will be 'xml' in XML 1.0 serialization, because the Infoset spec doesn't say so (or at least I didn't find something to that effect). This has to be nailed down here to avoid serializations such as <reason xmlns:foo='http://www.w3.org/XML/1998/namespace' foo:lang='... <reason> is a human-readable string, but there is no way for the request side to indicate which language would be preferred. This is a serious problem. Solutions may include the definition of a soap feature (preferably a module) for this, or requirements/ recommendations for bindings to make mechanisms they have available (e.g. Accept-Language for the HTTP binding). In some cases, it can make sense to send <reason> in more than one language. Is this allowed? It may be a good idea. <reason> is currently the only place where human readable text is used. But despite Web Services being primarily machine-to-machine, we expect that quite some applications will include data that is ultimately targeted at humans, or will have to make some part of their processing dependent on human language and culture. This seems to indicate that some more work will have to be done.[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP WG has decided to modify SOAP Reason element (5.4.2 in Part1) in the following manner: - The Reason element information item has one or more Text element information item children: <env:Reason> <env:Text xml:lang="en-US">wrong color</env:Text> <env:Text xml:lang="en-GB">wrong colour</env:Text> </env:Reason> - The Text element information item has any number of character information item children to explain the neture of the fault. - Each Text element MUST have xml:lang attribute information item (prefix of lang attribute information item MUST be "xml:"). - When there are multiple Text element information items, values of xml:lang attribute information items MUST be unique. Applications can make multiple language versions of the fault text available using this mechanism. Applications could negotiate the language for the fault text using a mechanism built using SOAP headers. However we do not provide such a mechanism.[email] |
|||||||
264 | spec | n/a | Editorial | Design | Closed | Martin Duerst | |
Title: Part 0 - section 6 - URIs | |||||||
Description:
6. This section should make it clear that soap uses the XML Schema type 'anyURI', and that therefore characters outside US-ASCII are allowed, but have to be mapped to URIs via UTF-8 (i.e. SOAP essentially uses IRIs, refer to XML Schema or XLink for conversion details) if e.g. the underlying protocol doesn't support IRIs. There also should be a requirement to deal with this in the binding framework, and an explanation of how to deal with this in the HTTP binding, as well as some tests (I can help with the tests). Also, a note in the Primer would help.[email] |
|||||||
Proposal: | |||||||
Resolution:
The editors decided to resolve this issue with no action. The full rationale can be found at [3] but essentially we deemed that it is out-of-scope for our spec to say anything about IRIs given they are already covered by the XML Schema Part 2 specification [4].[email] |
|||||||
265 | spec | n/a | Editorial | Design | Closed | Martin Duerst | |
Title: Part 0 - section 7.3 - Feature conflicts | |||||||
Description:
7.3: feature conflict between soap features and features in the underlying protocol: This is a general issue, not only for security. It should be mentioned in the chapter on bindings.[email] |
|||||||
Proposal: | |||||||
Resolution:
The XML Protocol WG has decided to close editorial issue 265 raised by you without changes to the specification. The justification follows below. If you cannot accept this resolution then please send your concerns to the <xml-dist-app@w3.org> mailing list indicating the issue number of the issue in the subject. We believe the issue of interacting features, regardless of whether they are expressed as SOAP modules or part of the binding) is covered in part 1, section 3.2 where it is stated that a SOAP module specification: "MUST clearly specify any known interactions with or changes to the interpretation of the SOAP body. Furthermore, it MUST clearly specify any known interactions with or changes to the interpretation of other SOAP features (whether or not those features are themselves modules). For example, we can imagine a module which encrypts the SOAP body and inserts 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."[email] |
|||||||
266 | spec | n/a | meta | Design | Closed | Martin Duerst | |
Title: Part 2 - Mixed content representation | |||||||
Description:
2: How is XML mixed content represented in this graph model? Can it be represented? If not, this is a serious problem for internationalization.[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP WG has decided to close this issue without any change to the SOAP Data Model and without any change to the SOAP Encoding. The XMLP WG recognizes the general importance of enabling I18N, however SOAP's model and serialization is designed for interfacing with programming languages many of which we believe would be incapable of dealing with the resulting marked up text. Indeed, there has been early experience (e.g. on "soapbuilders") binding the SOAP Encoding to a large number of widely deployed systems (e.g. Java, .Net, etc.) We have reason to believe that most, perhaps all of these would be incapable of effeciently representing (e.g. in their Unicode string types) the sort of marked up text that is conveyed by mixed content. We realize that this decision is at best a practical compromise from the point of view of i18n. We believe, however, that the sensible order of attack on this problem is to first encourage the development of programming systems that can indeed efficiently manipulate such richly structured text. At that point, it would indeed be sensible to consider "raising the bar" and providing at least an option for mixed content in the SOAP encoding. In the meantime, we do not believe that we can adopt an approach that would substantially break most or all of our existing users' implementations. The XMLP WG notes that the SOAP Data Model and Encoding are optional, and the SOAP framework allows someone to create their own model with a serialisation that provides mixed content.[email] |
|||||||
267 | spec | n/a | Editorial | Design | Closed | Martin Duerst | |
Title: Part 2 - section 3.1.2 Editorial. | |||||||
Description:
3.1.2: encoding simple values: There should be a note mentioning that most characters in the C0 range cannot be represented in XML.[email] |
|||||||
Proposal: | |||||||
Resolution:
The XML Protocol WG has decided to close issue 267 raised by you by adding a note in SOAP 1.2 part 2, section 3.1.2 saying: Note that certain Unicode characters cannot be represented in XML (see [XML 1.0]).[email] |
|||||||
268 | spec | n/a | meta | Design | Closed | Martin Duerst | |
Title: Part 2 - properties datatypes | |||||||
Description:
5.1.1: Properties are restricted to simple datatypes. This may cause serious problems for internationalization.[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP Working Group have closed Issue 268 with the following resolution: Change the following text from Part 2 5.1.1 [2]; 'Property values are typed, and the type of a property-value is defined by an XML Schema simple datatype in the specification which introduces the property. For example, the type of RetryCount is xsi:int .' To read: 'Where appropriate properties SHOULD have an XML Schema type' The WG will also update the property tables to include a 'Type' column.[email] |
|||||||
269 | spec | n/a | Editorial | Design | Closed | Martin Duerst | |
Title: Part 2 - section 7.5.1.3 - editorial | |||||||
Description:
7.5.1.3: response MAY be of content type other than application/soap+xml: add a note saying that care is needed because different content types may have different rules for the 'charset' parameter.[email] |
|||||||
Proposal: | |||||||
Resolution:
The XML Protocol WG has decided to close issue 269 without making changes to the SOAP 1.2 specification. The reason for the decision is stated below. The issue reads as follows 7.5.1.3: response MAY be of content type other than application/soap+xml: add a note saying that care is needed because different content types may have different rules for the 'charset' parameter. However, in Table 18 [5] which is just above the paragraph you mention (and which is the target of the paragraph), we say that: "The response message is assumed to be a SOAP envelope serialized according to the rules for carrying SOAP messages in the media type given in the Content-Type header field." The only other place where we mention possible media type encodings is in Table 15 [6] where we say: "SOAP message serialized according to the rules for carrying SOAP messages in the media type given by the Content-Type header field. Rules for carrying SOAP messages in media type "application/soap+xml" are given in A. "The application/soap+xml Media Type". In both places do we state that it is the responsibility of the media type to dictate the rules for the encoding. As the parameter "charset" is part of a specific media type definition, the WG felt that it is out of scope of the HTTP binding to refer to the use of the charset parameter. For the specific case of "application/soap+xml" of which registration is undertaken by the XML Protocol WG, issues related to the use of the charset parameter are explicitly described in appendix A.[email] |
|||||||
270 | spec | n/a | Editorial | Design | Closed | Martin Duerst | |
Title: Part 2 - Appendix A - Editorial | |||||||
Description:
- Appendix A: This needs a major overhaul (Masahiro Sekiguchi already pointed out some problems quite a while ago). - Start with some introductory text explaining what's going on. - XML Name has two parts -> An XML Name ... - Let Prefix be computed: There is really no computation going on at all. - In order from left to right -> In order from first to last (otherwise, you get problems with bidirectionality) [but this will drop out anyway] - 2: change to: Let TAG be a name in an application, represented as a sequence of characters encoded in a particular character encoding. - 3: change to: Let UNI be the sequence of characters of TAG transcoded to Unicode with a normalizing transcoder (using NFC), and let M<sub>1</sub>, M<sub>2</sub>, ... , M<sub>N</sub> be the characters of UNI, in order from first to last. - Add a note: The number of characters in TAG is not necessarily the same as the number of characters in UNI, because transcoding may be one-to-many or many-to-one. The details of transcoding may be implementation-defined. There may be (very rarely) cases where there is no equivalent Unicode representation for TAG; such cases are not covered here. - remove 4. - Change all T<sub>foo</sub> to M<sub>foo</sub> in the rest. - Remove 5.1, moving up 5.2,... - Say explicitly that hex digits always use upper case letters. - Add examples with non-ASCII characters, both in the BMP (not only Latin-1) and outside the BMP.[email] |
|||||||
Proposal: | |||||||
Resolution:
The XML Protocol WG has decided to close issue 270 raised by you by applying substantial amount of editorial work in order to clarify the text [2], which for other reasons now is in Appendix B and not Appendix A. The rewrite also took into account contributions and suggestions by Asir S Vedamuthu [3] and Mike Champion [4]. The comments raised by Mike are logged as issue 341 [4] for which a separate closing text will be generated.[email] |
|||||||
271 | spec | n/a | Editorial | Design | Closed | Martin Duerst | |
Title: General - acknoledgments section | |||||||
Description:
Acknowledgements: I assume that the 'member of the WG' "Noah Mendelson (IBM)" and the the 'previous member of the WG' "Noah Mendelson (Lotus Development)" are one and the same person. This would appropriately be reflected by saying 'member of the WG': "Noah Mendelson (IBM, formerly Lotus Development)". There are other cases like this (apologies to Noah for picking him as an example).[email] |
|||||||
Proposal: | |||||||
Resolution:
The XML Protocol WG has decided to close issue 271 raised by you by adjusting the list of present and former WG members and their affiliations. You can find the updated list for present members at [2] and former members at [3]. For obvious reasons, the lists may of course still change.[email] |
|||||||
272 | spec | n/a | Editorial | Design | Closed | Martin Duerst | |
Title: Part 0 - editorial comments | |||||||
Description:
My impression is that this is not really a primer. Even the first example is already very long. In various places, issues such as GET vs. POST,... are discussed. Although such issues are very important, their discussion in the Primer seems to be more a reflection of the fact that tehy were disucssed extensively in the WG, rather than being written with careful consideration for beginners. (...) 2.2.2, "Part 2 Section 4.1.1provides": ed.: space missing. There are other places where a space before or after a link got lost. 2.4, last table (unnumbered): having two columns, one for intermediary and another for ultimate receiver, seems completely unnecessary. (...) 3.1.1, "RDF format for the itinerary might have been choosen": There are too many might, could,... in the spec overall. This is a typical example. 3.1.2, before example 13: ed: that the all the -> that all the[email] |
|||||||
Proposal: | |||||||
Resolution:
This comment has been incorporated into the editor's copy of the Primer[email] |
|||||||
273 | spec | n/a | Editorial | Design | Closed | Martin Duerst | |
Title: Part 0 - 1.1, 'pure information retrieval' and GET | |||||||
Description:
1.1, 'pure information retrieval': GET requests can be used very appropriately for many more things than 'pure information retrieval'. Assume a web service that accepts XML Schema dates and returns dates formatted e.g. for Japanese cheques. While the service would do calculations, it would have a very high cachability.[email] |
|||||||
Proposal: | |||||||
Resolution:
This comment has been incorporated into the editor's copy of the Primer[email] |
|||||||
274 | spec | n/a | Editorial | Design | Closed | Martin Duerst | |
Title: Part 0 - Content-Type missing. | |||||||
Description:
3.2, example 14: Content-Type missing.[email] |
|||||||
Proposal: | |||||||
Resolution:
This comment has been incorporated into the editor's copy of the Primer[email] |
|||||||
275 | spec | n/a | meta | Design | Closed | Martin Duerst | |
Title: Part 0 - This currently doesn't look very inviting | |||||||
Description:
3., paragraph starting with 'However, a soap message may travel': This and other places show how 'weak' soap currently is. Rather than being a well-defined, complete protocol layer that can easily be used from higher layers and mapped to lower layers, it seems to be a collection of options, and even for the simplest uses, a large number of things have to be selected/specified again by each application. This currently doesn't look very inviting.[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP WG has discussed your comment on the SOAP 1.2 Primer, and decided to close it with no change to the referenced section of the Primer. The referenced primer text merely captures in informal terms some aspects of the protocol binding framework specified or implied in the normative parts of the SOAP specification. Thus your comment appears to be a general observation on what you feel to be the shortcomings of the SOAP binding framework rather than a request for specific changes to the Primer.[email] |
|||||||
276 | spec | n/a | Editorial | Design | Closed | Martin Duerst | |
Title: Part 0 - Why does the sender need soap | |||||||
Description:
3.2, just before example 14: Why does the sender need soap capabilities? Somebody could just send a soap message in an email with a simple mua, couldn't they?[email] |
|||||||
Proposal: | |||||||
Resolution:
This comment has been incorporated into the editor's copy of the Primer[email] |
|||||||
277 | spec | n/a | meta | Design | Closed | Martin Duerst | |
Title: Part 1 - general comments | |||||||
Description:
General: The use of URIs in some places and qnames in other places is arbitrary and very confusing. Except for element/attribute names, URIs should always be used. This would also simplify mapping to description languages,... General: Compared to other W3C specs, soap uses a very large number of namespaces. Many of these namespaces in turn are used for very few things. This creates an unnecessary overhead in particular for small messages (as they may e.g. be used on small devices), and overall seems quite unnecessary.[email] |
|||||||
Proposal: See email and email. | |||||||
Resolution:
Issue 277 contains two parts: 1 - The use of URIs in some places and qnames in other places is arbitrary and very confusing. Except for element/attribute names, URIs should always be used. This would also simplify mapping to description languages,... 2 - Compared to other W3C specs, soap uses a very large number of namespaces. Many of these namespaces in turn are used for very few things. This creates an unnecessary overhead in particular for small messages (as they may e.g. be used on small devices), and overall seems quite unnecessary. Part 1 resolution: Since your review of the spec, it has evolved, and in several places the usage of QNames has been replaced by the usage or URIs. Furthermore, the working group has agreed upon the following resolution for closing this first part of the issue: - in Part 1, 5.4.1.3 SOAP Value Element (with Subcode parent) we continue using QNames for representing the SOAP Value Element in Faults. <rationale> this may be inconsistent with other usage of QNames, but the WG thinks that the change to URIs was not necessary and would have a great impact on current implementation of SOAP 1.2. </rationale> - in Part 1, 5.4.7 VersionMismatchFaults - in Part 1, 5.4.8 mustUnderstand Faults - in Part 2, 2.2 Graph Nodes - in Part 2, 3.1.4 Computing the Type Name property - in Part 2, 3.1.4.1 itemType Attribute Information Item we continue using QNames in those places. <rationale> in all those places, QNames are used for refering to Element Information Item Names or Attribute Information Item Names. Consequently, the WG thinks the usage of QNames is appropriate. </rationale> - in Part 2, 5.1.1 Properties we will name properties with URIs rather than with QNames. <rationale> it seems more coherent to use URIs here, and the change should not have too much impact on current implementations. </rationale> Part 2 resolution: - Keep http://www.w3.org/2002/06/soap-envelope namespace. <rationale> This is the main spec namespace. </rationale> - Merge http://www.w3.org/2002/06/soap-faults namespace and http://www.w3.org/2002/06/soap-upgrade namespace into http://www.w3.org/2002/06/soap-envelope namespace. <rationale> Both namespaces are used in the main part of the SOAP 1.2 specification and are tightly linked with the processing of SOAP messages. </rationale> - Keep http://www.w3.org/2002/06/soap-encoding namespace. <rationale> This namespace is used for defining aii in an independant part of the spec. </rationale> - Keep http://www.w3.org/2002/06/soap-rpc namespace. <rationale> This namespace is used for defining an eii in an independant part of the spec. </rationale> - Remove http://www.w3.org/2002/06/soap/mep/ namespace and http://www.w3.org/2002/06/soap/mep/FailureReasons/ namespace. <rationale> They are not used anymore. </rationale> - Remove http://www.w3.org/2002/06/soap/bindingFramework/ExchangeContext/ namespace, http://www.w3.org/2002/06/soap/mep/request-response/ namespace and http://www.w3.org/2002/06/soap/features/web-method/ namespace. <rationale> Those namespaces were only used for identifying properties with QNames. As properties are now identified with URIs, they are not used anymore. </rationale> In addition the WG agreed to change the name of the envelope Element Information Item found in the old http://www.w3.org/2002/06/soap-upgrade namespace to supportedEnvelope to avoid collision with the envelope Element Information Item found in the http://www.w3.org/2002/06/soap-envelope namespace.[email] |
|||||||
278 | spec | n/a | Editorial | Design | Closed | Martin Duerst | |
Title: Part 1 - editorial | |||||||
Description:
Example 1 (nit): The message should probably expire a bit later, to avoid that it's never seen because the receiver didn't have time at the right moment. 2.6: "at-most one fault" -> "at most one fault" 2.7.1: Re-inserting ... emphasizes the need to process them at each soap node ...: weird wording. Maybe: Processing is defined here in terms of reinserting (rather than leaving things in place) to emphasize the need .... 5.2.3: "MAY be omitted if its value would have been ...": another example of 'would'. 5.3.1: Please add: "* May have any number of element or attribute children." It would be strange if body child elements had to be CDATA only. 7.1 ed: side affects -> side effects 7.3.1 ed: 'associated that protoco': 'with' missing.[email] |
|||||||
Proposal: | |||||||
Resolution:
>Example 1 (nit): The message should probably expire a bit >later, to avoid that it's never seen because the receiver >didn't have time at the right moment. Example 1 has NOT been changed. The point is that if the message is not processed before 2pm then it's too late. >2.6: "at-most one fault" -> "at most one fault" done >2.7.1: Re-inserting ... emphasizes the need to process them at >each soap node ...: weird wording. Maybe: Processing is >defined here in terms of reinserting (rather than leaving >things in place) to emphasize the need .... Now says: "Processing is defined here in terms of re-inserting header blocks (rather than leaving them in place) to emphasize the need to process them at each SOAP node along the SOAP message path." >5.2.3: "MAY be omitted if its value would have been ...": >another example of 'would'. Now says: "A SOAP intermediary MAY omit the SOAP mustUnderstand attribute information item if its value is "false" >5.3.1: Please add: "* May have any number of element or >attribute children." It would be strange if body child >elements had to be CDATA only. done >7.1 ed: side affects -> side effects done >7.3.1 ed: 'associated that protoco': 'with' missing. done[email] |
|||||||
279 | spec | n/a | Editorial | Design | Closed | Martin Duerst | |
Title: Part 1 - active intermediaries | |||||||
Description:
2.7.2 Active Intermediaries: Are these part of the processing model, or is this a way to 'cheat' around the processing model? It sounds as if they can do just about anything, which looks highly suspicious.[email] |
|||||||
Proposal: | |||||||
Resolution:
The XML Protocol WG has decided to close issue 279 without changes to the specification. The reason is that SOAP 1.2 part 1, section 2.7.2 [2] already states that active intermediaries must follow the same rules as forwarding intermediaries: "In addition to the processing performed by forwarding intermediaries, active intermediaries undertake additional processing that can modify the outbound message in ways not described in the inbound message."[email] |
|||||||
280 | spec | n/a | Editorial | Design | Closed | Martin Duerst | |
Title: Part 1 - change the SOAP Processing Model | |||||||
Description:
3.2, point 2: Is it allowed to just change the soap processing model? In arbitrary ways? or are there restrictions?[email] |
|||||||
Proposal: | |||||||
Resolution:
You have asked whether SOAP Modules were allowed to change the soap processing model in arbitrary ways, or whether they are any restrictions (Part 1, Section 3.2, bullet 2 [now bullet 3]). The XMLP WG has decided to close issue 280 by adding the following text: "The SOAP extensibility model does not limit the extent to which SOAP can be extended. Nor does it prevent extensions from modifying the SOAP processing model from that described in Section 2.6"[email] |
|||||||
281 | spec | n/a | Editorial | Design | Closed | Martin Duerst | |
Title: Part 1 - multiple features | |||||||
Description:
4.2, multiple features: 'MUST provide any info necessary for their successful use in combination': Is it okay to say 'feature A and B cannot be used together', or is this not allowed?[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP WG has closed this issue by incorporating the following text into Part 1. --------------------- Revised text: In cases where multiple features are supported by a binding specification, the specifications for those features MUST provide any information necessary for their successful use in combination. Similarly, any dependencies of one feature on another (i.e. if successful use of one feature depends on use or non-use of another) MUST be specified. This binding framework does not provide any explicit mechanism for controlling the use of such interdependent features.[email] |
|||||||
282 | spec | n/a | Editorial | Design | Closed | Martin Duerst | |
Title: Part 2 - Editorial | |||||||
Description:
Intro: ed) The list of points (1.-7.) mixes full sentences and nominal phrases, which is very awquard to read. 2.2.1, title (ed): looks strange. I suggest something like 'single-reference and multi-reference nodes'. 3.: A simple example showing a model graph and one or two possible encodings is urgently needed because it will make reading and understanding this section a lot easier for a lot of people. 3.1.6: ed [2] nextConcreteSize ::= " " concreteSize: The notation for space is confusing. Better use something explicit (such as S 4.1.2: "the 6.4 Web Method Specification Feature feature": 'feature feature' sounds weird. (ed) 4.2.2, 3rd bullet point: It is unclear here if a return value has to be present for a procedure that can return various values, one of which being 'void', in the case where the actual return value is 'void'. (yes seems the correct answer to me, to avoid counting wrong, but then how exactly will this be represented) 4.2.3, 1st para: '<body> MUST contain only a single child element' and 'is constrained to produce a single tree' are not the same. The former can lead to a graph e.g. with cycles as long as all nodes in the graph can be reached by following edges starting from a single node. (such a thing is probably called a 'single-rooted graph', but maybe it's called something else). >>>> tem 4: 'or when there is a mismatch ...': This mismatch has to be clarified/restricted, otherwise everything can be a env:Sender fault. 4.4, Note: 'if the receiver does support' ??? 'if the receiver does NOT support' seems to make more sense. 5.1.2 The figure should be numbered and labeled, and should be redone to look sharper. (ed) 6.2.2 This should make clear that there are no soap intermediaries. (I hope I got this right) 7.1, ed: performingsimilar: add space 7.5.1.2, 415: support Content-type: add 'the' ed 500: an SOAP fault->a SOAP fault table 21, ed: 'has generating': fix grammar[email] |
|||||||
Proposal: | |||||||
Resolution:
The editors have incorporated your suggested changes, albeit the ones listed below: * Did NOT change title of 2.2.1. * Have not put examples into section 3, this should go into the primer instead. * Did NOT change 3rd bullet of 4.2.2.[email] |
|||||||
283 | spec | n/a | Editorial | Design | Closed | Martin Duerst | |
Title: Part 2 - enc:MissingID | |||||||
Description:
3.2: enc:MissingID: this sounds right only in some cases. In others, 'DuplicateID' or so seems better, or change to 'IDProblem' or so if you want just one subcode.[email] |
|||||||
Proposal: | |||||||
Resolution:
You have raised an issue enc:MissingID vs. enc:DuplicateID. The XMLP WG has decided to close this issue by adding enc:DuplicatedID and modifying the prose accordingly. Note that we have *not* provided a subcode for the case where *both* id and ref attributes appear on an element.[email] |
|||||||
284 | spec | n/a | Editorial | Design | Closed | Martin Duerst | |
Title: Part 2 - 'binding-specific address of the target soap node' | |||||||
Description:
4. 'binding-specific address of the target soap node': My understanding up to here was that soap nodes were identified by an (any)URI, without this being binding-specific. Please clarify here or earlier.[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP WG has decided to adopt your suggested change of removing "binding-specific" in the sentence "binding-specific address of the target soap node".[email] |
|||||||
285 | spec | n/a | Editorial | Design | Closed | Martin Duerst | |
Title: Part 2 - App B - Clarifications | |||||||
Description:
B: 'validation ... MUST NOT be required by conforming processors': Does this mean: 'conforming processors are not required to validate' or 'it is forbidden that a conforming processor validates' or what? B: Could there be a feature/module requiring validation in a certain way (rather than this being purely application-level)? B2: 'Validation against the minimum schema will not succeed': WHY? This seems wrong. B3: '...schemas could be constructed ... certain graphs': Why only graphs? Couldn't it be just about any kind of data?[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP WG has decided to clarify Appendix B (now Appendix C) as per your request for clarification. Changes to this appendix are highlighted [2] in red (deletions) and green (additions).[email] |
|||||||
286 | spec | n/a | Editorial | Design | Closed | Martin Duerst | |
Title: Part 2 - Is a soap intermediary a http intermediary? | |||||||
Description:
7.1, first note: Is a soap intermediary a http intermediary?[email] |
|||||||
Proposal: | |||||||
Resolution:
You asked whether in 7.1, first note, the intermediary was "a soap intermediary or an http intermediary"? The XMLP WG has decided to closed this issue by inserting the following text: "(which may or may not also be SOAP intermediaries)"[email] |
|||||||
287 | spec | n/a | Editorial | Design | Closed | Philippe Le Hégaret | |
Title: Part 0 - Example 7b - contradicting text and table | |||||||
Description:
2.4 SOAP Processing Model: (this section would better with more subsections) [...] Example 7b [...] <r:aThirdBlock xmlns:r="http://example.com"> :::: </r:aThirdBlock> [...] In Example 7b, the ultimate recipient of the message - the SOAP processor which plays the "ultimatereceiver" role - must process both the Body as well as the header block aThirdBlock. [...] Node intermediary ultimate receiver mustUnderstand "true" must process must process "false" may process may process absent may process may process [...] Does the ultimate receiver must process the block aThirdBlock as described in the text or may process it, as described in the table?[email] |
|||||||
Proposal: | |||||||
Resolution:
This comment has been incorporated into the editor's copy of the Primer[email] |
|||||||
288 | spec | n/a | Editorial | Design | Closed | Philippe Le Hégaret | |
Title: Part 1 - notations | |||||||
Description:
General comment: as a user, this specification is difficult to read. The Infoset-like notation would be better with a BNF notation. I wish the editors didn't follow the example of the XML Schema specification before rewriting the SOAP spec. The style used plays against the technology described in the specification imho. It is unfortunate that SOAP and WSDL are not used the same conventions for markup. SOAP uses capitalized-word and WSDL lowercases. I noticed that SOAP Part 1 contains several occurences of "mustUnderstand" and "MustUnderstand" btw.[email] |
|||||||
Proposal: | |||||||
Resolution:
After carefull examination, the XMLP WG rejected your proposal to use BNF instead of Infoset. The WG also wishes to point out that "mustUnderstand" (lowercase "m") is an attribute, and "MustUnderstand" (capital "M") is a fault code. In accordance, the WG has decided to close this issue without any further action.[email] |
|||||||
289 | spec | n/a | Editorial | Design | Closed | Philippe Le Hégaret | |
Title: Part 1 - How does an intermediary do when receiving a fault? | |||||||
Description:
Section 5.4: How does an intermediary do when receiving a fault? Is it guarantee to be forwarded to the original Sender (or previous intermediary) if known?[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP WG has decided to close issue 289 without any further action. The WG considers that the precise definition of the forwarding feature is out-of-scope for this specification.[email] |
|||||||
290 | spec | n/a | Editorial | Design | Closed | Philippe Le Hégaret | |
Title: Part 1 - How does a SOAP Node know the SOAP version to use? | |||||||
Description:
Section 5.4.7: The envelope (lowercase, without namespace name) element is used to indicate a mismatch SOAP version in the Envelope (capitalized, with namespace name) element. How does a SOAP Node know the SOAP version to use?[email] |
|||||||
Proposal: | |||||||
Resolution:
Rereading the specification, I realized that the response to my question is in fact described in the envelope documentation: [[ The Upgrade header block consists of an Upgrade element information item containing an ordered list of qualified names of SOAP envelopes that the SOAP node supports in the order most to least preferred. ]][email] |
|||||||
291 | spec | n/a | meta | Design | Closed | Philippe Le Hégaret | |
Title: Part 1 - Why does the envelope element not have a namespace name? | |||||||
Description:
Why does the envelope element not have a namespace name?[email] |
|||||||
Proposal: | |||||||
Resolution:
The XML Protocol (XMLP) WG has decided to close issue 291, which you originated, with the following resolution. 1. The "envelope" element is renamed to "Envelope" 2. The (new) "Envelope" element is made part of the "http://www.w3.org/2002/06/soap-upgrade" namespace[email] |
|||||||
292 | spec | n/a | meta | Design | Closed | Jacek Kopecky | |
Title: RPC and Encoding fault combinations | |||||||
Description:
In SOAP Encoding [1] it says that a SOAP receiver >>SHOULD generate an "env:Sender" SOAP fault with a subcode of enc:MissingID if the message violates the constraints on id and ref attribute information items (see 3.1.5.3 Constraints on id and ref attribute information items).<< In SOAP RPC [2] it says that >>A fault with a Value of "env:Sender" for Code and a Value of "rpc:BadArguments" for Subcode MUST be generated when the receiver cannot parse the arguments or when there is a mismatch between what the receiver expects and what the sender has sent.<< It is unclear what should happen when both these conditions are met - RPC server cannot parse arguments because of a missing ID. Technically, the RPC fault is a MUST and the Encoding fault is a SHOULD, so the former takes precedence, but is this the intention? I'd like a clarification on the relationship of these faults.[email] |
|||||||
Proposal: | |||||||
Resolution:
The WG agreed with your concern and decided to close this issue by adding the following text to section 2.6 of SOAP 1.2 Part 1[2]: "A message may contain or result in multiple errors during processing. Except where the order of detection is specifically indicated (as for mustUnderstand faults above), 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."[email] |
|||||||
293 | spec | n/a | Editorial | Design | Closed | J-J Moreau | |
Title: Editorial - Primer - replace "::::" by "..." | |||||||
Description:
Examples I would suggest replacing the following symbols: :::: (i.e. 4 colons) by the more widespread notation: ... (i.e. 3 dots [ellipsis]).[email] |
|||||||
Proposal: | |||||||
Resolution:
This comment has been incorporated into the editor's copy of the Primer[email] |
|||||||
294 | spec | n/a | meta | Design | Closed | J-J Moreau | |
Title: part2 - message exchange context out of nowhere? | |||||||
Description:
Message Exchange Context The notion of Message Exchange Context (MEC) is central to the Binding Framework. However: * No formal definition for it is given in the glossary. There is only a vague description for it in part 2, section 5.1.2. * No real indication is given as to how a MEC is initialized or, possibly, transferred. For example, how does a SOAP node determine it should instantiate "context:ExchangePatternName" to "http://www.w3.org/2002/06/soap/mep/request-response/" and not to something else? IMO, part 2 should be explicit, either saying this is implementation specific, or providing a standard means for indicating, for example, the features being used.[email] |
|||||||
Proposal: See proposal. See second proposal. | |||||||
Resolution:
On last weeks telcon I took an action to flesh out my proposed resolution for issue 294 to show the text to be added to the spec. Here it is. <current> 5.1.2 Property Scope Properties within a SOAP node can differ in terms of their scope and the origins of their values. Some properties are scoped per message-exchange, while others have a wider significance. For example, the scope of a SOAP message property is per message-exchange, but the scope of a User Identity property may extend beyond the exchange of a single message. The values of some properties arise directly from the operations of the SOAP node and message exchanges, while others arise in implementation specific ways due to the local environment. As shown in the figure below, we make the distinction between per message-exchange and more widely scoped properties by assigning them to different containers called Message Exchange Context and Environment respectively. All properties, regardless of their scope, are shared by SOAP and a particular Binding. <Graphic caption="Model describing properties shared between SOAP and Binding"/> The values of properties in Environment may depend upon local circumstances (as depicted by the external arrow from Environment in the figure above). More specifically, the properties in the example could be influenced by an Operating System User ID on whose behalf a message exchange is being executed. The mapping of information in a particular implementation to such properties is outside the scope of the binding framework although the abstract representation of such information as properties is not. </current> <proposed> 5.1.2 Property Scope Properties within a SOAP node differ in terms of their scope and the origins of their values. As shown in the figure below, we make the distinction between per message-exchange and more widely scoped properties by assigning them to different containers called Message Exchange Context and Environment Context respectively. All properties, regardless of their scope, are shared by a SOAP node and a particular Binding. <Graphic caption="Model describing properties shared between SOAP and Binding"/> 5.1.2.1 Message Exchange Context A message exchange context is a collection of properties whose scope is limited to an instance of a given message exchange pattern. An example of a message exchange context property is the identifier of the message exchange pattern in use. 5.1.2.2 Environment Context The environment context is a collection of properties whose scope extends beyond an instance of a given message exchange pattern. Examples of environment context properties are the IP address of the SOAP node or the current date and time. The values of properties in Environment may depend upon local circumstances (as depicted by the external arrow from Environment in the figure above). More specifically, the properties in the example could be influenced by an operating system user ID on whose behalf a message exchange is being executed. The mapping of information in a particular implementation to such properties is outside the scope of the binding framework although the abstract representation of such information as properties is not. </proposed> <current> 7.5 MEP Operation For binding instances conforming to this specification: * A SOAP node instantiated at an HTTP client may assume the role (i.e. the property context:Role ) of "RequestingSOAPNode". * A SOAP node instantiated at an HTTP server may assume the role (i.e. the property context:Role ) of "RespondingSOAPNode". The remainder of this section describes the MEP state machine and its relation to the HTTP protocol. In the state tables below, the states are defined as values of the property context:State (see 6.2 SOAP Request-Response Message Exchange Pattern), and are of type xs:anyURI . For brevity, relative URIs are used, the base URI being the value of context:Role . </current> <proposed> 7.5 MEP Operation For binding instances conforming to this specification: * A SOAP node instantiated at an HTTP client may assume the role (i.e. the property context:Role ) of "RequestingSOAPNode". * A SOAP node instantiated at an HTTP server may assume the role (i.e. the property context:Role ) of "RespondingSOAPNode". The remainder of this section describes the MEP state machine and its relation to the HTTP protocol. In the state tables below, the states are defined as values of the property context:State (see 6.2 SOAP Request-Response Message Exchange Pattern and 6.3 SOAP Response Message Exchange Pattern), and are of type xs:anyURI. For brevity, relative URIs are used, the base URI being the value of context:Role. The message exchange pattern in use is indicated by the HTTP method used in the request. HTTP GET corresponds to the SOAP-Response MEP, HTTP POST corresponds to the SOAP Request-Response MEP. </proposed> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Oct/0118.html -- Marc Hadley --------------------------------------------------- From [3]: Posting on behalf of Jacek. Based on today's XMLP WG meeting, and addition to Marc's proposal. ====================================== 7.4 Supported Features An implementation of the SOAP HTTP Binding MUST support the following feature: * "http://www.w3.org/2002/06/soap/features/web-method/" (see 6.4 Web Method Specification Feature) <addition> The possible values of webmeth:Method property are restricted in this HTTP binding according to the MEP in use (as present in context:ExchangePatternName): context:ExchangePatternName | webmeth:Method --------------------------------------------------------+----------------- "http://www.w3.org/2002/06/soap/mep/request-response/" | "POST" "http://www.w3.org/2002/06/soap/mep/soap-response/" | "GET" Note: other SOAP Version 1.2 bindings to HTTP may permit other combinations of context:ExchangePatternName and webmeth:Method. </addition> ======================================[email] |
|||||||
295 | spec | n/a | Editorial | Design | Closed | Paul Prescod | |
Title: URI/RPC Primer Changes | |||||||
Description:
The Primer implies that using URIs correctly is only important in an RPC context. But the truth is that *whenever* SOAP is used over HTTP, the SOAP specification recommends that the URI should be resource-identifing. The primer also has a confusing paragraph-ordering in that it concentrates on resource retrievals and then switches to mentioning POST later. Reading the beginning of the section you would never expect what comes at the end. ===== I propose to change the title: change: 3.1.3 Conveying Web-friendly RPCs to: 3.1.3 Web-friendly SOAP Messages Then I propose to add at the very beginning: add: "One of the most central concepts of the World Wide Web is that of a URI as a resource identifier. SOAP services that use the HTTP binding and wish to interoperate with other Web software should use URIs to address all important resources in their service." Then I propose to start the next paragraph with the phrase "For example," change: A very important - indeed predominant - use ... to: "For example, a very important - indeed predominant - use of the World Wide Web is pure information retrieval, " Next I propose to remove references of the word "RPC" to indicate that the points made are more general than RPC: change: There are many instances when RPCs are designed .... to: There are many instances when messages are designed .... change: with a parameter of the RPC representing the object ..... to: with an element of the body representing the object .... I do not believe that the word "typical" should be used to describe the historical SOAP/RPC behaviour. Hopefully in a year what is typical will have changed. change: In the typical SOAP/RPC usage scenario, the HTTP ... to: In some SOAP/RPC implementations, the HTTP .... More removals of the over-specific "RPC": change: Even in this case, the HTTP POST with a SOAP message conveying the RPC can be represented in a Web-friendly manner. to: Even in this case, the HTTP POST with a SOAP message can be represented in a Web-friendly manner. change: As with the use of the GET, Part 2 recommends that any part of the RPC signature that serves to: As with the use of GET, any part of the message that serves change: The same parameters may, of course, be retained in the encoded RPC in the SOAP Body element. to: The same parameters may, of course be retained in the SOAP Body. change: Note, however, that the all the parameters in the RPC signature.... to: Note, however that all of the resource-identifying elements have been retained[email] |
|||||||
Proposal: | |||||||
Resolution:
This comment has been incorporated into the editor's copy of the Primer[email] |
|||||||
296 | spec | n/a | Editorial | Design | Closed | Peter Drayton | |
Title: Message in Example 2 in Primer doesn't match prose exactly | |||||||
Description:
SOAP Version 1.2 Part 0: Primer, Section 2.2.1, Example 2: The prose describing the message says that the message is returned from the travel service, requesting clarification on the choice of airports in the departing city. However, the message itself doesn't (a) contain any indication that it is a request for clarification; (b) indicate if the request pertains to the outbound leg or the inbound leg; (c) indicate if the request pertains to the departure or arrival airport of a specific leg. It is possible to claim that the target node provides the context for processing the message, i.e the message might be sent to different endpoints depending on which leg & choice of arrival/departure requires clarification, and the endpoints might know that they are participating in a conversational exchange and understand the flow, but I don't think this is very clear. It also seems strange to me that the same <itinerary> element is sent in both directions, with different child elements and meaning. I don't think this is as clear as it could be for a primer. I'd suggest modifying example 2 to make the flow of messages back and forth clearer. For example: <?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"> <env:Header> <m:reservation xmlns:m="http://travelcompany.example.org/reservation" env:role="http://www.w3.org/2002/06/soap-envelope/role/next" env:mustUnderstand="true"> <m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference> <m:dateAndTime>2001-11-29T13:35:00.000-05:00</m:dateAndTime> </m:reservation> <n:passenger xmlns:n="http://mycompany.example.com/employees" env:role="http://www.w3.org/2002/06/soap-envelope/role/next" env:mustUnderstand="true"> <n:name>John Q. Public</n:name> </n:passenger> </env:Header> <env:Body> <q:itineraryClarification xmlns:q="http://travelcompany.example.org/reservation/travel/"> <q:departure> <q:departing> <q:airportChoices> JFK LGA EWR </q:airportChoices> </q:departing> </q:departure> <q:return> <q:arriving> <q:airportChoices> JFK LGA EWR </q:airportChoices> </q:arriving> </q:return> </q:itineraryClarification> </env:Body> </env:Envelope> This structure mirrors the prose, presuming the prose meant "...namely the choice of airports in the departing city *on both the outbound and the inbound legs*". If the prose meant to only request clarification on one of the legs, the sample could obviously be simplified.[email] |
|||||||
Proposal: | |||||||
Resolution:
Thank you for your comment, which has been listed as Issue 296 in the SOAP 1.2 Last Call Issues List. Your suggestion appears to be a good one, and I shall include it in the next revision of the SOAP 1.2 Primer.[email] |
|||||||
297 | spec | n/a | meta | Design | Closed | Jacek Kopecky | |
Title: Generic compound types unnecessary | |||||||
Description:
It is Systinet's position that the 'generics' in the SOAP Data Model are unnecessary and their handling is unclear. We don't see any use for 'generics' in the known uses of SOAP Encoding. See also the posponed issue 185 [in 5].[email] |
|||||||
Proposal: | |||||||
Resolution:
the Working Group has decided to close issue 185 [1] and last call issue 297 by removing generics from the SOAP Data Model (see bullet 1 in section 2.3 of Adjuncts [3]). The rationale for this decision is that the WG agrees with the originator of the issues that generics are unnecessary in the Data Model. The issue was discussed among the implementors (see latest discussion thread [6]) and among the xml-dist-app community (see the latest discussion thread [7]) without reaching any obvious consensus. Additionally, the working group has asked for feedback on this issue by introducing an editorial note at the end of section 2.3 of Adjuncts [3] that asks explicitly whether generics should remain or should be removed. The prevalent feedback has indicated that generics should be removed. Also, the implementors among the WG members have confirmed that they would welcome removing generics, with one exception of WebMethods, who prefer generics to stay but don't oppose the majority of the members. Note that issues 365 [4] and 366 [5] are affected by this decision, too.[email] |
|||||||
298 | spec | n/a | meta | Design | Closed | Jacek Kopecky | |
Title: RPC array representation unnecessary | |||||||
Description:
It is Systinet's opinion that the array representation of RPC invocation and results is unnecessary. The 'struct' representation suffices because in most interface description languages invocation parameters do have names. The situation is similar to that of another W3C recommendation - RDF, where properties are unordered and container membership properties are named _1, _2 etc. to achieve ordering - [6]. We are aware that adding array representation is the resolution for issue 180 [in 5], but we are not planning to implement this part of the SOAP RPC Representation. (The same comment can apply to arrays in the SOAP Data Model but we'd call it "going too far". 8-) )[email] |
|||||||
Proposal: | |||||||
Resolution:
This is to inform you that the XMLP WG has decided to close the Last Call issue 298 by removing the array representation from the SOAP RPC Representation, sections 4.2.1, 4.2.2 [2,3]. Also, mentions of this representation will be removed from sectsion 4 a 4.2.3 [5,6]. The rationale: the WG has agreed with the initiator of the issue that the array representation is unnecessary to achieve interoperable RPC using SOAP. Currently, WSDL doesn't support normative description of RPC services with positional parameters; furthermore, implementors from various member companies have indicated that they would welcome removing the array representation of RPC in SOAP. Lastly, array representation caused some interoperability problems recorded in the soapbuilders archive [4].[email] |
|||||||
299 | spec | n/a | meta | Design | Closed | Jacek Kopecky | |
Title: RPC return value accessor too complex | |||||||
Description:
It is Systinet's opinion that the current way of identifying the RPC return value in the RPC result struct (via a known parameter) is too complex a solution for the problem and that it obscures the representation. Nevertheless, our implementation does support this; the concern is for ease of understanding for newcomers to SOAP. <Amended when closing issue 245> This issue also covers issue 245 </Amended when closing issue 245>[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP WG has decided to close issue 299 without taking any action. The group felt that, although there is merit to your point about the complexity of the RPC return value mechanism, a change now would affect current implementations and that there is a risk to change at this last stage in the process. Users have an option to not use this in their implementations.[email] |
|||||||
300 | spec | n/a | meta | Design | Closed | Jacek Kopecky | |
Title: How is version transition handled in the HTTP binding? | |||||||
Description:
In Part 1, appendix A [3], the handling of SOAP 1.1 messages by SOAP 1.2 nodes is specified. It says that a node can generate a SOAP 1.1 version mismatch fault. In SOAP 1.1 messages travel via the HTTP binding using the content-type text/xml, whereas in SOAP 1.2 the messages travel using the content-type application/soap+xml. Is the version transition still practical if current SOAP 1.1 nodes only accept text/xml SOAP messages; so when they receive a "known" SOAP fault, it has an "unknown" content-type and therefore may not be recognized as a known fault?[email] |
|||||||
Proposal: See Henrik's proposal | |||||||
Resolution:
In response to issue 300 raised by you against the SOAP 1.2 Last Call specification, the WG has decided to incorporate the text provided in [1], which we believe clarifies the issue at hand.[email] |
|||||||
301 | spec | n/a | meta | Design | Closed | Jacek Kopecky | |
Title: Missing universal transport binding | |||||||
Description:
The SOAP 1.2 HTTP binding defines a binding to an application protocol; i.e. it only supports one application, and that is HTTP itself (also known as REST). Shouldn't the SOAP specification also contain at least one transport binding that can be used for all SOAP applications? We suggest a TCP binding.[email] |
|||||||
Proposal: Gudge proposes that we rule this out-of-scope and close it with no action. email | |||||||
Resolution:
The XMLP WG has decided to close issue 301 which you raised with no action taken. The proposal to create a universal transport binding is considered out of scope as defined by the charter, which requires the WG to produce only one binding [2] (section 2.3).[email] |
|||||||
302 | spec | n/a | meta | Design | Closed | Jacek Kopecky | |
Title: Data Model edges originating and not terminating | |||||||
Description:
In the SOAP Data Model it is said about graph edges that they are said to originate at a graph node and terminate at a graph node. In Encoding section 3.1.3 bullet 4 it says that "if a graph edge does not terminate in a graph node then..." Is it possible (from the point of view of the Data Model) for an edge not to terminate in a graph node? Isn't it contrary to the common definition of a graph edge? The SOAP Data Model doesn't define the term "edge" so the common definition has to be accepted. Our understanding is that there are no such edges (not terminating in a graph node); there may be "missing edges" instead that can be described in bullet 4 section 3.1.3.[email] |
|||||||
Proposal: | |||||||
Resolution:
The working group has decided to close this issue by adding the following text to Section 2.1 [3] "An edge MAY have only an originating graph node, that is be outbound only. An edge MAY have only a terminating graph node, that is be inbound only."[email] |
|||||||
303 | spec | n/a | meta | Design | Closed | Jacek Kopecky | |
Title: Fault for broken array attributes? | |||||||
Description:
While SOAP Encoding specifies faults that are generated in cases like missing ID and missing type; it does not specify faults that should be generated in case of malformed encoding attributes (like arraySize and itemType) and in case of inconsistency between the array size and the actual number of members.[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP WG has closed its issue #303 judging that it is not necessary to do anything and that the status quo is good.[email] |
|||||||
304 | spec | n/a | meta | Design | Closed | Jacek Kopecky | |
Title: No one-way MEP | |||||||
Description:
SOAP is a messaging protocol. Before MEPs are introduced, it is inherently one-way. One-way MEP is a widely used one and one that's exploited in WSDL 1.1; the basis for another W3C specification-in-progress, WSDL 1.2. Moreover, SOAP Abstract Model has a one-way operation as one of the two basic operations. Also, the resolution [7] to issue 38 says that "the SOAP 1.2 specification makes it easy to exchange one way and two-way messages." Also, issue 179 deals with one-way messaging; the resolution to this issue makes one-way messaging optional in bindings. Altogether, we'd like to see the SOAP 1.2 specification not only enable, but also provide a spec for one-way messaging.[email] |
|||||||
Proposal: | |||||||
Resolution:
This is to inform you that the XMLP WG has decided to close its Last Call issue 304 with no changes to the SOAP 1.2 specs. The WG acknowledges the importance of a one-way Message Exchange Pattern, but the SOAP 1.2 specification is intentionally written as extensible so that any party may add MEPs (or bindings and other components). It is possible that the XMLP WG produces a one-way MEP later. Such a document need not be synchronized in time with SOAP 1.2 specification.[email] |
|||||||
305 | spec | n/a | meta | Design | Closed | Jacek Kopecky | |
Title: The SOAP Response MEP doesn't need sending+receiving states | |||||||
Description:
(related to issue 239, maybe covered by it) It is unclear why this MEP needs the sending+receiving states in the state machines when there is nothing really that is sent from the requester to the responder. This also affects the states figure.[email] |
|||||||
Proposal: See Henrik's proposal and following thread. | |||||||
Resolution:
The WG agreed with your analysis and has closed this issue by renaming the SOAP Repsonse states as follows: (i) Requesting SOAP node state "Sending+Receiving" becomes "Receiving"[2] (ii) Responding SOAP node state "Receiving+Sending" becomes "Sending"[2] The HTTP binding [3] was also modified to include new sections describing these states.[email] |
|||||||
306 | spec | n/a | meta | Design | Closed | Jacek Kopecky | |
Title: Is use of Appendix A optional? | |||||||
Description:
It is unclear in the RPC Representation whether the links to Appendix A are a MUST (an identifier MUST be mapped to an XML name using Appendix A's algorithm) or a MAY (for a possible mapping algorithm see Appendix A).[email] |
|||||||
Proposal: See thread | |||||||
Resolution:
The Appendix titled "Mapping Application Defined Names to XML Names" will be referenced from the appropriate sections of the SOAP 1.2 Part 2 spec that describes the RPC Representation (probably sections 4.2.1 and 4.2.2), and the mandate for using the mapping will be "SHOULD". More exact wording can be found in [2] (although this will be modified slightly to accomodate at least one other issue resolution).[email] |
|||||||
307 | spec | n/a | meta | Design | Closed | Adam Souzis | |
Title: overrestrictive constrainsts for "SOAP header block" and "SOAP Body child Element"? | |||||||
Description:
Unless I'm missing something, the spec appears to disallow children elements for the child element information items of both the SOAP Header and the SOAP Body. See: 5.2.1 SOAP header block 5.3.1 SOAP Body child Element Both sections only state that they "MAY have any number of character information item children" but there is no mention allowing element information item children. Perhaps you intended to define the "SOAP header block" and "SOAP Body child Element" as descendents of the SOAP Header and the SOAP Body element information items respectively and not as just the children? As it stands now most of examples given in the spec are invalid, for example, Example 1 in Part 1, because n:priority is a child element of the "SOAP header block" n:alertcontrol and because m:msg is a child element of the "SOAP Body child Element" m:alert. If the authors did indeed intend this restriction and these are indeed invalid examples, then I'm sure I would not be alone in protesting this as overly restrictive constraints.[email] |
|||||||
Proposal: | |||||||
Resolution:
We acknowledge that this is a bug. The spec will be changed to allow header and body blocks to have element and character information items as children. Thank you for bringing this error to the attention of the Working Group.[emai] |
|||||||
308 | spec | n/a | Editorial | Design | Closed | Don Box | |
Title: Editorial comments on Primer (RPC) | |||||||
Description:
I am concerned that the Primer reinforces the myth that there are in fact two (and only two) distinct worlds: document and rpc. It does this by (a) calling out non-RPC applications by name (document), (b) discussing RPC-specifics too early and (c) intermingling RPC-isms in other broad/general concepts. Moreover, the specific examples seemed to have a very artificial distinction. Granted, the primer needs to address RPC-specifics such as <rpc:result> and the convention of encoding the operation/method name as the QName of the first child of Body. I'm all for that! However, given that less than 5% of the normative specs even discuss RPC (1842 words out of a total of 37042), it felt very strange that RPC wound up permeating the primer as it did. Also, there seems to be factoring issues, in that there is a co-mingling of the presentation of broad SOAP features inside the RPC sections. Specifically, in section 2.2.2 of the primer, the paragraph beginning with "RPCs may also require additional information..." as this issue is NOT specific to RPC but rather to any app that needs to augment the schema/content of the body with additional contextual goo.[email] |
|||||||
Proposal: | |||||||
Resolution:
- Section 2.2.1 has been renamed "Conversational message exchanges", although this by itself may not not fully address the myth (document vs. rpc) that you feel is being propagated. However, the WG does not believe that the Primer propagates such a view. The examples are sufficiently varied - although following one overall theme - to suggest the many uses of SOAP. In the RPC examples, the same example has been repeated in a different section to emphasize a different aspect, e.g., syntax in one section but a transfer mechanism in another. It would help if you could point out specific text in [0] where you feel the reader may be so misled. - Early in the formulation of the contents of the Primer, the WG decided that the document should build up from the more straightforward scenarios - single message, request-response, fault handling,...- to the more complex features. Thus RPC was placed where it is today. - As handling RPCs remains a requirement on SOAP 1.2 and a very common usage pattern currently, it is inevitable that there should be an emphasis on it in the Primer. In particular, a few more examples were chosen as RPCs to convey how not to do it in a Web Architecture incompatible way. This may account for the seeming emphasis. - Following other LC comments which have also suggested that section 2.2.2 should concentrate on the RPC syntax issues, the discussion of web architecture compatibility has been removed from that section; section 3.1.3 concentrates on the web architecture compatible ways of conveying rpcs. - Re you comment on section 2.2.2 "RPCs may require additional information...", please note that this was motivating the addition of a SOAP header in the example, to provide an example of item 6 from the list earlier in the section, the list itself being taken from part 2 describing RPCs. However, an additional note has been added (please see [0] same para) to point out that such info is not RPC specific.[email] |
|||||||
309 | spec | n/a | Editorial | Design | Closed | Dave Beckett | |
Title: Comments on Primer - QNames | |||||||
Description:
My main concern that stood out is the use of XML qnames, the (namespace name, local name) pair, for identifiers. This doesn't seem particular webby to me - URIs are the web's identifiers. The TAG has been discussing this: (DRAFT) TAG Finding: Using Qualified Names (QNames) as Identifiers in Content http://www.w3.org/2001/tag/doc/qnameids.html but offers mostly observations. This seemed relevant: "Using QNames in untyped (#PCDATA or xs:string) attribute values or element content places an additional burden on the processor that was not anticipated by [XML Namespaces]." Please consider this draft finding and the SOAP use of qnames. In particular, SOAP seems to use all of qnames, uris and CDATA in attribute values and element content as identifiers and it isn't clear to me coming to this new, when this choice is made or why.[email] |
|||||||
Proposal: | |||||||
Resolution:
The XML Protocol issue #309 has been closed by the XML Protocol working group who felt that it is a duplicate of issue #227 which is still to be resolved.[email] |
|||||||
310 | spec | n/a | Editorial | Design | Closed | Dave Beckett | |
Title: Comments on Primer - Editorial - xmlns | |||||||
Description:
2.1 m:reference contains something as element that could be a URI but could look like a qname too given the use elsewhere of qnames in element content. Note why xmlns attributes are defined at the most local place in env:Body rather than on doc element. I assume this is a convention for these examples rather than required, which "In Example 1, the header contains two header blocks, each of which is defined in its own namespace" so are namespaces part of the SOAP model? Are these XML namespaces? Either way - if they are, mention it, if not, add an explanation --- "The <tt>Body</tt> element ..." I would rather the <tt>env:Body</tt> element was used throughout if talking about that precise thing rather than the element local name <tt>Body</tt>. In this case the example uses <tt>env:Body</tt>, so changing it makes it more consistent.[email] |
|||||||
Proposal: | |||||||
Resolution:
This comment has been incorporated into the editor's copy of the Primer[email] |
|||||||
311 | spec | n/a | Editorial | Design | Closed | Dave Beckett | |
Title: Comments on Primer - Editorial - example 4 | |||||||
Description:
2.2.2 Example 4 has the t:transaction "5" hanging about like this: ... env:mustUnderstand="true" > 5 </t:transaction> which took me a while to work out that it was the element content. Maybe just me. It has some additional odd formatting: </m:reservation> <o:creditCard xmlns:o="http://mycompany.example.com/financial"> and indenting that doesn't help reading the XML structure (and SOAP structs): <o:expiration>2005-02</o:expiration> </o:creditCard> Example 4 title says two "in" parameters How are the parameters 'in'? It isn't clear from the example. Is that the default? Is it decided out of band?[email] |
|||||||
Proposal: | |||||||
Resolution:
This comment has been incorporated into the editor's copy of the Primer[email] |
|||||||
312 | spec | n/a | Editorial | Design | Closed | Dave Beckett | |
Title: Comments on Primer - Editorial - examples 7/7a - 5a | |||||||
Description:
2.3 Example 7 - why is xmlns:f defined on env:Envelope and not the env:Header or f:Misunderstood elements? Is it convention again? General note: Also noticed some XML args are using '', some "" I understand these are equivalent, it just stands out to me. 2.4 Example 7a elided example stands out as curious why SOAP mixing use of qnames URIs, and CDATA for identifiers i.e. why: <p:oneBlock xmlns:p="http://example.com" env:role="http://example.com/Log"> and not: <p:oneBlock xmlns:p="http://example.com" env:role="p:Log"> I guess it is suuppose roles are expected to be defined as an unlimited set of terms, ie URIs, rather than as names in an XML namespace. I'm comparing to earlier use of the attribute env:encodingStyle (takes URI value), env:mustUnderstand attribute (takes CDATA with a fixed set of terms), env:Value element (takes qname value from fixed set of terms) It isn't obvious when to use these or why qnames/CDATA are chosen for fixed sets of terms. -- The phrase 'actor attribute' suddenly appears in middle of a paragraph, and related to, the ultimateReceiver role and talks about the absence of such an attribute indicating such a role, when actors have never before been discussed! (this is the first use of the word) Is this a typo, and 'role attribute' was meant? I noticed later on in the changes that the role attribute was renamed from earlier versions, maybe this needs updating. -- "The body element" para? should be <tt>Body</tt> since talking about the element, not the general SOAP body. -- in the unlabeled table "The following table summarizes how the processing actions" both columns are the same - why is this table needed? General: please add numbers, titles (summary?), anchors to all tables and link to them. -------- Example 5a has different indenting levels, style from Example 4 - please make them consistent. Example 5a 'out' parameters - how is that indicated in this example? Unlike the example 5b which uses rpc:result, this example has no such indicator.[email] |
|||||||
Proposal: | |||||||
Resolution:
This comment has been incorporated into the editor's copy of the Primer[email] |
|||||||
313 | spec | n/a | Editorial | Design | Closed | Dave Beckett | |
Title: Comments on Primer - Editorial - Formatting & typos | |||||||
Description:
3.1 para 3,4 formatting HTTP:1)the -> HTTP: 1) the ofHTTP -> of HTTP Acceptheader => Accept header General: this suggests more spell checking needed throughout if these weren't caught. The HTML uses <span>s around them, so that might be the cause. 3.1.2 Example 9 formatting near o:creditCard needs fixing as above 4.2 why are 'encoding schemes' labelled with an attribute called env:encodingStyle ? Surely this should be env:encodingScheme? sec 6 - references don't seem to be in right document style from the W3C Style guide. 'Latest version ..' links etc. missing General The HTML uses style="color: #000000" etc. May be better as CSS classes and possibly with other emphasis methods for better accessibility.[email] |
|||||||
Proposal: | |||||||
Resolution:
This comment has been incorporated into the editor's copy of the Primer[email] |
|||||||
314 | spec | n/a | Encoding | Design | Closed | Dan Brickley | |
Title: Comments on part 2 - URI/URIref names | |||||||
Description:
Summary: Reading back, my comments are variations on a theme: the SOAP Encoding and its Data Model would benefit from a more explicit account of the mechanisms by which node and edge types for use in SOAP graphs might be defined. There are a few places where the use of URIs might make it easier for other successor specs to flesh out such details (eg. URIs for kinds of edge label, for nodes, for node types). URIs: I specifically request one change to the spec in the light of implementation experience with SOAP: please specify a mechanism for identifying SOAP graph edge labels with URI/URIref names. Identifying nodes and their types would be useful, but identifying and describing SOAP edge labels is (in my database-oriented implementation) critical. We have a number of other activites at W3C that could support the richer description of SOAP graph edge labels: Web Service Description effort, RDF and RDF Schema, as well as the Web Ontology work. Providing URI/URIref names for graph edges is a very minimalistic hook that will make integration with such efforts cheaper and simpler, without adding to the implementation burden for SOAP implementations. (...) [[ 2.1.1 Edge labels An edge label is an XML Schema Qualified Name (see XML Schema Part 2: Datatypes) ]] Spec change request: Please specify an algorithm (for example, simple concatenation) by which SOAP graph edge types (labels) can be named using URI/URIref syntax. This will make it much easier for out-of-band metadata, including but limited to RDF/XML metadata, to provide further information about the kinds of edges deployed in SOAP Encoding applications. For example, I have a SOAP encoding application (using SOAP 1.1, being upgraded...) in which the serialised objects represent software packages. It uses edge labels such as 'ownerMailbox', 'homepage' etc. If these had URIs, we could write external RDF/XML descriptions about those edge labels, for example mapping to other SOAP Data Model constructs from similar applications created elsewhere, or specifying mathematical characteristics of the graph (eg. that certain edge labels have an 'at most one' semantic, a characteristic that can support graph merging algorithms and hence Web Service aggregation). (more details of this on request... I want to get these comments in before last call closes or would provide examples from the implementation) question: What is the relationship between node types and edge label types in SOAP encoding? Can they be mixed freely? Can I use node types defined (somehow...) by one application, with instances of that node using edge labels drawn in multiple other schemas? Are there any rules constraining the sensible combinations of node and edge types. Specifically, does the type of a node determine the edges that be attached to it? Does each kind of edge label have node types that they can point to and from? Implementor feedback: I am storing and merging de-serialised SOAP Encoding messages in a database system. To implement, I had to assume an answer to these questions. I assumed that the SOAP Data Model allowed namespace mixing amongst types and edges, and that node types do not dictate the edge types for a node. [[ 2.2 Graph Nodes [...] Both types of graph node have an optional unique identifier of type ID in the namespace named "http://www.w3.org/2001/XMLSchema". ]] Since the SOAP Data Model is defined in the abstract, separate from any specific XML (or non-XML) syntactic encoding, it isn't clear why XML's notion of ID is being used here. The spec says the node has a "unique identifier", but does not define the scope of this uniqueness. XML IDs are unique within some document. Is this an implicit constraint on all SOAP Data Model XML encodings, ie. that we have the rule of one Data Model graph per XML document? (to avoid unique ID clashes). Is the ID unique within the scope of one graph, or one encoding as an entire XML document of such a graph? request: please allow nodes to be identified by URI/URIref (same goes for node types btw; I won't recycle this comment for that part of the spec). so, please allow nodes, and their types, to be identified by URI/URIref. The use of a global unique identifier here (ie. URI/URIref) would remove the question of identifier scope, since in a Web (Service) context, URI identifiers won't accidentally clash. This might help decouple the abstract Data Model from the specifics of its XML encoding. It would also support data merging between SOAP graphs that shared node identifiers, but that's an added bonus.[email] |
|||||||
Proposal: | |||||||
Resolution:
1. The XMLP WG will not define a mechanism for assigning URIs to graph edges. For the purposes of SOAP Data Model and Encoding, QNames are sufficient. 2. The XMLP WG will not specify an algorithm for generating URIs from QNames. We note that the RDFCore WG have previously considered a similar issue[5]. We also note that the TAG are considering this issue[6] 3. The XMLP WG will remove the ID property from nodes. It's presence was an oversight on behalf of this editor. IDs are only needed at serialization time and hence only need to appear in the encoding not in the data model. We also note that the navigation model for the SOAP Data Model is one of traversal rather than one based on node identity. This end the resolution of Issue 314. Regarding other questions you raise in Issue 314 You asked: Q1: What is the relationship between node types and edge label types in SOAP encoding? A1: Not defined. Q2: Can they be mixed freely? A2: Yes Q3: Can I use node types defined (somehow...) by one application, with instances of that node using edge labels drawn in multiple other schemas? A3: Yes Q4: Are there any rules constraining the sensible combinations of node and edge types. A4: No Q5: Specifically, does the type of a node determine the edges that be attached to it? A5: No Q6: Does each kind of edge label have node types that they can point to and from? A6: No Note that the answers to the above are based on my own understanding of your questions and how the SOAP data model works. I should note that I'm not ENTIRELY sure I understand what you mean by 'node type'. You could mean: a) The type property of the node b) Whether the node is a generic, struct or array c) Something else I've not though of However, if it's a or b then the answers stand. If it's c then get back to me ( on xml-dist-app@w3.org please )[email] |
|||||||
315 | spec | n/a | meta | Design | Closed | Dan Brickley | |
Title: Test cases / machine checkable test suite: | |||||||
Description:
I don't comment on the fine-grained detail of the SOAP Encoding itself, except to say the following: please seriously consider creating a machine-usable test suite for this work. Defining a graph encoding syntax in XML is a slippery task, and it is easy to make mistakes, both in the specification and in implementations. Apparent interop amongst deployed SOAP toolkits may reflect shared understanding in that part of the Web community as much as it reflects precision in the formal specification of the encoding rules. As this work moves into the wider Web community, we'll likely see more unexpected corner cases. Historical note: this happened with RDF and the RDF/XML graph encoding syntax. We had to clean up RDF's graph encoding rules post-REC. As a result of that experience, we have reworked the RDF specs to use a more mathematically precise account of the abstract graph model, accompanied by a machine-processable set of test cases. See http://www.w3.org/RDF/ for details. I urge the XMLP WG to gather similar test cases before proposing SOAP 1.2 goes to REC. It's very easy to get bugs in XML graph encoding rules. Having a test suite offers very useful protection against this[email] |
|||||||
Proposal: | |||||||
Resolution:
There are concrete specification of tests related to encoding in the Test Collection. Various SOAP/1.2 messages are available for testing SOAP/1.2 encoding and many SOAP/1.2 endpoints are already available. Also, groups are already actively engaged into testing SOAP/1.1 and we expect they will do the same for Version 1.2.[email] |
|||||||
316 | spec | n/a | Encoding | Design | Closed | Dan Brickley | |
Title: Comment on part 2 - SOAP Data Model | |||||||
Description:
- -> http://www.w3.org/TR/soap12-part2/#datamodel [[ 2. SOAP Data Model The SOAP Data Model represents application-defined data structures and values as a directed edge-labeled graph of nodes. Components of this graph are described in the following sections. ]] The concept of 'application-defined' is somewhat unclear: are these data structures defined by the producers of the data, by consumers? what form do these definitions take? Might we expect to read a schema definition (W3C XML Schema? RELAX-NG?) that made such definitions explicit, or are the definitions expected to be implicit. For example, if I deploy a Java-based SOAP service, my application-defined data structures might be described in terms of Java, yet exposed to the world through the SOAP Encoding Data Model. Readers of 1.2p2 could reasonably ask: 'what technology can I use to to expose my application-defined data structuring conventions? The SOAP 1.2p2 Encoding explains how to expose instance data, but gives little account of how the underlying principles that tell us whether or not a particular SOAP graph meets the 'application-defined data structures' for a given service. Is there an expectation that technology will evolve to fill this gap? (a SOAP Encoding Schema Language has been mentioned in some discussions on xml-dist-app and www-ws-desc). If so, please make this expectation clearer in the specification (there is an aside later in the spec, but it isn't very detailed). If not, please note that SOAP 1.2 does _not_ specify any mechanisms by which applications which use SOAP Encoding can describe the SOAP Encoded data structures they understand. [[ The purpose of the SOAP Data Model is to provide a mapping of non-XML based data to some wire representation. It is important to note that use of the SOAP Data Model, the accompanying SOAP Encoding (see 3. SOAP Encoding), and/or the SOAP RPC Representation (see 4. SOAP RPC Representation) is OPTIONAL. Applications which already model data in XML, for example using W3C XML Schema [4],[5], may not need to use the SOAP Data Model. ]] As an introduction to the role of the SOAP Data Model, this could be clearer. It explains that one might take the Schema-based approach, or that one might take the SOAP Encoding approach, but offers little to motivate either decision. For a fresh application with no existing commitment to a Schema-based approach, the specification currently offers little advice to help SOAP adopters choose which path to take. Are there identifiable benefits for using SOAP Encoding over a Schema approach? Perhaps (for example) that Web services can be deployed faster using object-to-XML encodings than through hand-crafting an XML Schema? The current text doesn't really sell us on the utility of SOAP Encoding; on the contrary, it has a somewhat wary, cautious tone, yet doesn't provide technical details on the tradeoffs. If you could add 2-3 bullet points to aid SOAP adopters make an informed decision here, that might help. [[ 2.1 Graph Edges An edge MAY originate and terminate at the same graph node. ]] addition clarification / test case: May a graph contain more than one edge with the same originating and terminating node? (and can such a thing be serialised? in the current Encoding rules? in other hypothetical encodings?) [[ The outbound edges of a given graph node MAY be distinguished by label or by position, or both. Position is a total order on such edges; thus any outbound edge MAY be identified by position. ]] This is a bit confusing. Whose freedom does the 'MAY' refer to? Consumers of the data? Or definers of a SOAP Data Model-based application data formats? (see above re Schema languages). The notion of 'position' is introduced with reference to 'such edges'. But which ones? All of them, since 'any outbound edge MAY be identified by position'? Are there edge types for which position is irrelevant? (does 'position relate to 'document order' in the concrete XML Encoding of the data model?). I'm not sure I understand this paragraph enough to comment sensibly. (...) [[ 2.3 Values If the labels of a non-terminal graph node's outbound edges are not unique (i.e. they can be duplicated), the non-terminal graph node is known as a "generic" ]] Seems odd. How do we know such things about edge labels? No mechanism has been described whereby we could acquire such metadata. [[ Outbound edges of a generic MAY be distinguished by label and/or position, according to the needs of the application. ]] Which application? This is even more confusing, unless I'm missing something. The impression I'm left with is that the meaning of a SOAP Data Model Graph is rather fluid, and open to competing, rival interpretations (eg. multiple consumer apps, or creators of namepsaces used in the encoding, vs creators of services that use those namespaces). If there was a SOAP Data Model schema language, it would presumably address constraints such as those described in 2.3. In its absence, there appears to be no authoritative account of the rules governing each kind of SOAP Data Model edge label. Section 2.3 should either be removed or augmented with a description of how (possibly out of band) metadata might provide such information in a machine-readable format. Without an account of this, word of mouth seems to be the only way to acquire such information.[email] |
|||||||
Proposal: | |||||||
Resolution:
We broke the issue into several questions: Q1: How do applications describe what they send/receive? A1: We consider it to be out of scope for our spec to define how applications that use the SOAP encoding to encode data describe their data structures. Q2: When should I use the SOAP encoding? A2: We do not consider it to be the job of our specification to tell people when to use the SOAP Encoding ( i.e. it's out of scope ) Q3: May a graph contain more than one edge with the same originating and terminating node? A3: Yes Q4: And can such a thing be serialised? Q4: Yes Q5: In the current Encoding rules? A5: Yes. E.g. <narcissus id='me'> <name>Martin</name> <bestfriend ref='me' /> <otherfriend ref='me' /> </narcissus> Q6: In other hypothetical encodings? A6: Yes ;-)[email] |
|||||||
317 | spec | n/a | Encoding | Design | Closed | Dan Brickley | |
Title: Comment on part 2 - misc comments | |||||||
Description:
Misc other comments: I understand SOAP sevices can now be deployed with a GET binding. This means we can expect to see things like HTML documents hyperlinking into SOAP services which return SOAP Encoding data graphs. - can these by styled with XSLT? eg. a stockticker might return XML for SOAP clients, but be XSLT'd into XHTML for humans. (ie. is it legal to include stylesheet PIs?) - can protocol oriented header information be ommitted? for simple lookups, we often might want nothing more than the graph data itself. Would this be legal? Could we use the SOAP mime type? - SOAP Encoding is a useful syntax for dumping programmatic objects into XML. Please consider making it easier for non-protocol uses to be made of it. I could easily drop object serialisations onto an FTP site, for example. Or deploy them on a normal HTTP server using normal HTTP content negotiation, so humans got an HTML version of a document, and SOAP clients got the graph encoding. The current spec doesn't seem to anticipate such re-use.[email] |
|||||||
Proposal: | |||||||
Resolution:
1)XSLT/PI -> out of scope (not an use case) 2)out of scope and no (as envelope is missing) 3)out of scope also[email] |
|||||||
318 | spec | n/a | Encoding | Design | Closed | Dan Brickley | |
Title: Comment on part 2 - encoding | |||||||
Description:
[[ 3.1 Rules for Encoding Graphs in XML ]] This bit of the spec is much improved from the previous WD; thanks! [[ 3.1.4 Computing the Type Name property Note: These rules define how the type name property of a graph node in a graph is computed from a serialized encoding. This specification does not mandate validation using any particular schema language or type system. [...] However, nothing prohibits development of additional specifications to describe the use of SOAP with particular schema languages or type systems. ]] This aside partly addresses some of my questions above. Perhaps it should have more prominence in the spec, since it (?) relates to edge types as well as node types, and to general issue of extensibility and further development of the Web service model. One clarification request: where it says 'the use of SOAP with particular schema languages', does this mean 'the use of the SOAP Encoding Data Model with particular schema languages? ie. are you leaving open the possibility that Web Services may be able to provide additional metadata about their use of the Encoding and associated Data Model? (and relating to edge labels and their characteristics, as well as node types). [[ ... Such additional specifications MAY mandate validation using particular schema language, and MAY specify faults to be generated if validation fails. Such additional specifications MAY specify augmentations to the deserialized graph based on information determined from such a validation. ]] This seems rather challenging from an extensibility and future proofing point of view. If I implement a SOAP 1.2 tookit now, including SOAP Encoding support, how would such running code know when it had encountered use of such an 'additional specification'? Is this a scenario where the SOAP 'mustUnderstand' mechanism should be used? If deployed 1.2 clients will be ignorant of 1.2++ services that use such mechanisms, this could cause problems.[email] |
|||||||
Proposal: | |||||||
Resolution:
Regarding section 3.1.4, part 2, paragraph 2, we are making editorial changes to clarify that we are referring to the SOAP Encoding. Regarding your final point, the SOAP extensibility model and the mustUnderstand attribute would serve to handle future needs of the type that you allude to.[email] |
|||||||
319 | spec | n/a | Binding | Design | Closed | Henrik Frystyk Nielsen | |
Title: Clarification that HTTP does define a base URI | |||||||
Description:
Section 6 paragraphs 4 and 5 [1] indicate that the base URI may be provided by the underlying transport, yet the referenced HTTP binding [2] in Part II makes no mention of this. In [1] it says: "The underlying protocol binding MAY define a base URI which can act as the base URI for the SOAP envelope (see 4. SOAP Protocol Binding Framework and Part 2 [1] section HTTP binding)." It seems like a useful clarification that we indicate that HTTP does provide a base URI which is the Request URI as described in [2].[email] |
|||||||
Proposal: | |||||||
Resolution:
The XML Protocol has decided to accept this proposal as the resolution to issue 319. Issue 319 mentions that it might be a useful clarification that because HTTP defines a base-URI in a couple of different ways, this propagates through the SOAP HTTP binding. The proposal is to include a paragraph in part 2 section 7.1 [2] saying: Note: HTTP/1.1 defines a base URI in the form of the Request-URI or the value of the Content-Location header field, see RFC 2616 for details.[email] |
|||||||
320 | spec | n/a | meta | Design | Closed | Henrik Frystyk Nielsen | |
Title: Clarification on Use of Multiple Fault Codes | |||||||
Description:
In [1], it is stated that: "SOAP fault codes are intended for use by software to provide an algorithmic mechanism for identifying the fault. The values of the Value child element information item of the Code element information item are restricted to those in Table 2. Additional fault subcodes MAY be created for use by applications or features. Such subcodes are carried in the Value child element information item of the Subcode element information item." However, the text says very little about what the semantics of multiple fault codes are and how these may relate to the SOAP Detail EII. For example, is the contents of the Detail EII entirely orthogonal to the fault codes, or do I have to understand the fault codes in order to properly understand the details? I think this should be stated in order to provide unambiguous semantics for SOAP faults. Something like this may work as clarifying text for [1]: SOAP Fault Codes ---------------- SOAP fault codes are intended for use by software to provide an algorithmic mechanism for identifying the fault. SOAP fault codes are organized as a linked list of XML qualified names allowing a SOAP node to identify the fault category at an increasing level of detail of the SOAP fault. This is similar to the model used in other application layer protocols like HTTP and SMTP. For example, in HTTP, there is a model of three-digit status codes where the first digit indicates the overall class of fault responses as described by RFC 2616. In SMTP, which also uses a three-digit status code, the three digits of the reply each have a special significance as described by RFC 2881: "The first digit denotes whether the response is good, bad or incomplete. An unsophisticated SMTP client, or one that receives an unexpected code, will be able to determine its next action (proceed as planned, redo, retrench, etc.) by examining this first digit. An SMTP client that wants to know approximately what kind of error occurred (e.g., mail system error, command syntax error) may examine the second digit. The third digit and any supplemental information that may be present is reserved for the finest gradation of information." The top-level fault code is reserved by this specification using the values defined by the faultCodeEnum type in the "http://www.w3.org/2002/06/soap-envelope" namespace. Additional fault subcodes MAY be created for use by applications or features. Such subcodes are carried in the Value child element information item of the Subcode element information item. SOAP fault codes are to be interpreted as modifiers of contents of the Detail EII in the sense that they provide the context for the contents of Detail EII. A SOAP node MUST understand all SOAP fault codes in a SOAP fault message in order to be able to interpret the Detail element in a SOAP fault. For example, if the Detail EII contains a timeout value, this value is to be interpreted in the context of the SOAP fault codes. In the example below, this means that the foo:MaxTime EII value is to be interpreted in the context of the env:Sender, foo:Timeout fault code list. <env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope" xmlns:foo="http://www.example.org/timeouts"> <env:Body> <env:Fault> <env:Code> <env:Value>env:Sender</env:Value> <env:Subcode> <env:Value>foo:MessageTimeout</env:Value> </env:Subcode> </env:Code> <env:Reason>Sender Timeout</env:Reason> <env:Detail> <foo:MaxTime>P5M</foo:MaxTime> </env:Detail> </env:Fault> </env:Body> </env:Envelope> This specification does not define a limit for how many Subcode EII a SOAP fault might contain. Implementations should always follow the Robustness Principle [2] for interpreting SOAP fault codes. However, while not a requirement of this specification, it is anticipated that most practical examples can be supported by relatively few Subcode EIIs." Table 2: SOAP Fault Codes ...continue with table contents...[email] |
|||||||
Proposal: | |||||||
Resolution:
The WG has accepted the following boiled down version of the proposal referenced in [1] for incorporation in SOAP 1.2 part 1, section 5.4.6 [2]: * * * * * SOAP fault codes are XML qualified names, and are intended to provide a means by which faults are classified. A hierarchical list of SOAP codes and associated supporting information is included in every SOAP fault message, with each such code identifying the fault category at an increasing level of detail. The values of the Value child element information item of the Code element information item are restricted to those defined by the env:faultCodeEnum type (see Table 2). Additional fault subcodes MAY be created for use by applications or features. Such subcodes are carried in the Value child element information item of the Subcode element information item. SOAP fault codes are to be interpreted as modifiers of the contents of the Detail element information item in the sense that they provide the context for the Detail element information item. A SOAP node MUST understand all SOAP fault codes in a SOAP fault message in order to be able to interpret the Detail element information item in a SOAP fault. * * * * *[email] |
|||||||
321 | spec | n/a | meta | Design | Closed | Henrik Frystyk Nielsen | |
Title: Two inconsistencies in SOAP-defined fault codes | |||||||
Description:
The schema for the SOAP 1.2 envelope [1] defines a faultcodeEnum which is used by the Value EII in the SOAP fault: <xs:complexType name="faultcode"> <xs:sequence> <xs:element name="Value" type="tns:faultcodeEnum"/> <xs:element name="Subcode" type="tns:subcode" minOccurs="0"/> </xs:sequence> </xs:complexType> <xs:simpleType name="faultcodeEnum"> <xs:restriction base="xs:QName"> <xs:enumeration value="tns:DataEncodingUnknown"/> <xs:enumeration value="tns:DTDNotSupported"/> <xs:enumeration value="tns:MustUnderstand"/> <xs:enumeration value="tns:Receiver"/> <xs:enumeration value="tns:Sender"/> <xs:enumeration value="tns:VersionMismatch"/> </xs:restriction> </xs:simpleType> However, the list is not consistent with the list in [2] which does not include "DTDNotSupported". I believe the consensus on this issue, which was reached in solving issue 191 [5], is that we do not define a "DTDNotSupported" fault code in which case it should be deleted from the schema. The other inconsistency is that we in the table do not indicate whether DataEncodingUnknown is a top-level fault code or a subcode. The place this comes up is in the HTTP binding where we map the top-level fault codes to HTTP fault codes. This was discussed as part of resolving issue 196 [3] and I believe the consensus was to make it a subcode of the Sender code. FWIW, I can live with it as a top-level fault, just don't want it to be an oversight.[email] |
|||||||
Proposal: | |||||||
Resolution: | |||||||
322 | spec | n/a | meta | Design | Closed | Henrik Frystyk Nielsen | |
Title: Clarification on Use of SOAP Detail Element | |||||||
Description:
I think the current description of the Detail EII in [1] is a leftover from early days but now comes across as inconsistent with the overall SOAP 1.2 processing model and the notion of multiple SOAP fault codes (see also [2]). Our processing model provides a clear model for what a fault means but the Detail element breaks this into two cases: faults resulting from header faults and from body faults. This separation is mediocre at best and has no impact on the processing of a SOAP message. As a result I suggest that we fix this by removing the distinction between header and body faults and allow the Detail EII to contain additional information in either case. That is, I suggest that we change the current text from [1]: "The Detail element information item MUST be present when the contents of the SOAP Body could not be processed successfully. It MUST NOT be used to carry error information about any SOAP header blocks. Detailed error information for SOAP header blocks MUST be carried within the SOAP header blocks themselves. The absence of the Detail element information item indicates that a SOAP Fault is not related to the processing of the SOAP Body . Presence of the Detail element information item is a signal that the SOAP Body was at least partially processed by an ultimate SOAP receiver before the fault occurred. All child element information items of the Detail element information item are called detail entries (see 5.4.5.1 SOAP detail entry)." And instead say: "The Detail element information item MAY be present in a SOAP fault carrying additional information relative to the SOAP fault codes describing the fault (see section X.X). For example, the Detail EII might contain information about a message not containing the proper credentials, a timeout, etc. The presence of the Detail EII has no significance as to which parts of the faulty SOAP message was processed. All child element information items of the Detail element information item are called detail entries (see 5.4.5.1 SOAP detail entry)."[email] |
|||||||
Proposal: | |||||||
Resolution:
The WG accepts the proposal and will change the spec accordingly.[email] |
|||||||
323 | spec | n/a | meta | Design | Closed | Henrik Frystyk Nielsen | |
Title: Use of "" in encodingStyle Attribute | |||||||
Description:
In section [1] defining the encodingStyle attribute, we have the same problem using an empty URI as we had in issue [2]: "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. If no encodingStyle attribute information item is in scope for a particular element information item or the value of such an attribute information item is the zero-length URI ("") then no claims are made regarding the encoding style of that element information item and its descendants." When we made the transition to use XMLBase throughout, "" became a valid relative URI and hence we can't use that to indicate that there is no encoding. Instead I suggest that we introduce an explicit URI that carries the same semantics but doesn't have this problem. An example of such a URI is http://www.w3.org/2002/06/soap-envelope/encoding/none[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP Working Group has closed Issue 323 by accepting your proposal: To indicate that no claim about the encoding style are made, the value for the encodingStyle attribute information item will be changed from "" to "http://www.w3.org/2002/06/soap-envelope/encoding/none".[email] |
|||||||
324 | spec | n/a | meta | Design | Closed | Henrik Frystyk Nielsen | |
Title: Clarification on Use of what SOAP Faults Mean when not Direct and Only Child of Body | |||||||
Description:
This is IMO purely editorial--in the text from [1]: "To be recognized as carrying SOAP error information, a SOAP message MUST contain a single SOAP Fault element information item as the only child of the SOAP Body . When generating a fault, SOAP senders MUST NOT include additional element information items in the SOAP Body . A message whose Body contains a Fault plus additional element information items has no SOAP-defined semantics. A SOAP Fault element information item MAY appear within a SOAP header block, or as a descendant of a child element information item of the SOAP Body ; in such cases, the element has no SOAP-defined semantics." I don't think the last sentence is correct. The question is not really whether it has SOAP-defined semantics but whether it is the result of the processing as defined in section 2.6 [2]. I suggest changing the last sentence to: "A SOAP Fault element information item MAY appear within a SOAP header block, or as a descendant of a child element information item of the SOAP Body; in such cases, the element is not indicating a failure in the processing of that message as defined by the SOAP processing model defined in [2]".[email] |
|||||||
Proposal: | |||||||
Resolution:
The WG decided to close the issue without making any change to the spec. The WG felt that the existing text conveys the correct and appropriate meaning.[email] |
|||||||
325 | spec | n/a | Encoding | Design | Closed | Anish Karmarkar | |
Title: Encoding - XML schema | |||||||
Description:
SOAP 1.2 does a great job of separating the SOAP data model and soap encoding. The aim of the soap data model (section 2) is to provide a mapping of non-XML based data to some wire representation (which is XML). The soap data model is a directed edge labeled graph, whereas the XML data model is tree based. Soap encoding (section 3) bridges this gap by providing a way to encode arrays and multirefs. But soap encoding does not use XML Schema to do this (except for the use of xsi:type to determine the Type Name property - section 3.1.4). We believe that XML schema is the only interoperable type system available in the existing XML technologies and that it is necessary to define an optional encoding that uses XML Schema (define a XML schema instance or provide a schema oriented solution) for serialization of soap data model.[email] |
|||||||
Proposal: | |||||||
Resolution:
At the sept. 4th 2002 telecon, the WG decided to close LC issue 325 by keeping status quo.[email] |
|||||||
326 | spec | n/a | meta | Design | Closed | Martin Gudgin | |
Title: Qualify attributes? | |||||||
Description:
Should all the attributes defined by the SOAP spec be namespace qualified? It would seem consistent that all attributes that appear on elements that are NOT in a SOAP namespace be qualified. I think this applies to all the attributes in the spec ( none of them appear on Envelope, Header or Body ). We qualify role and mustUnderstand, but not the other attribute like id/ref/itemType.[email] |
|||||||
Proposal:
I raised this issue at last call. The proposal is that we qualify all attributes in our spec. This means making the id and ref attribute information items qualified. This brings them into line with itemType and arraySize ( and mustUnderstand and role ).email] |
|||||||
Resolution:
The working group has decided to close this issue by qualifying all the attributes in the specification. Specifically the id and ref attributes will be qualified by the soap-encoding namespace.[email |
|||||||
327 | spec | n/a | meta | Design | Closed | Ray Whitmer | |
Title: Intellectual property | |||||||
Description:
We feel that there may be significant intellectual property issues with the SOAP specification. Multiple companies have said they believe they may have relevant patents. Further investigation is required here before the specification should proceed to PR phase. There is also a bit of divergence in some cases between IPR disclosures and grants in the SOAP 1.1 submission and the SOAP 1.2 specification and the IPR summary for SOAP should encompass declarations from both lists and reconcile them where different statements were made by the same companies. These aggregate statements need to be considered and compared with the W3C definitions of royalty-free, looking for unacceptable terms which have been stipulated.[email] |
|||||||
Proposal: see David's email and following thread | |||||||
Resolution:
The WG has resolved issue 327 which you originated and as described in http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2002Dec/0094.html.[email] |
|||||||
328 | spec | n/a | Editorial | Design | Closed | Philippe Le Hégaret | |
Title: Minor editorial change - part 2 | |||||||
Description:
In Part 2: 6.1 Property Conventions for Message Exchange Patterns -> 6.1 Property Conventions for SOAP Message Exchange Patterns 6.2 Request-Response Message Exchange Pattern -> 6.2 SOAP Request-Response Message Exchange Pattern[email] |
|||||||
Proposal: | |||||||
Resolution:
The WG discussed this issue recently and agreed to make the changes you requested.[email] |
|||||||
329 | spec | n/a | meta | Design | Closed | Mike Champion | |
Title: Possible inconsistency in SOAP Process Model | |||||||
Description:
SOAP1.2 Part 1: Messaging Framework 2.4 Understanding SOAP Headers, 3rd paragraph, 2nd sentences "Therefore, for every mandatory SOAP header block targeted to a node, that node MUST either process the header block or not process the SOAP message at all, and instead generate a fault ..." This sentence implies that there can be at most one detection of a fault caused by processing a header block as all further message processing ceases on fault detection. However, in various parts of Part 1, there is assumption that multiple misunderstood header blocks may be possibly identified in a fault message, e.g. in 2.6 Processing SOAP Messages, Rule 3: "If one or more of the header blocks identified in the preceding step are not understood by the node ..." e.g. in 5.4.8 SOAP mustUnderstand Faults, 2nd paragraph, 1st sentence: "A SOAP node MAY generate a SOAP fault for any one or more SOAP header blocks ..." Related commentary on this issue: "A SOAP node MAY generate a SOAP fault for any one or more SOAP header blocks that were not understood in a SOAP message." This sentence is very ambiguous and seems to conflict with this sentence from section 2.4 Understanding SOAP Headers: "for every mandatory SOAP header block targeted to a node, that node MUST either process the header block or not process the SOAP message at all, and instead generate a fault" My understanding (according to section 2.4) is that the SOAP node MUST generate a SOAP fault for the first SOAP header block that is targeted at that node, contains mustUnderstand="true", and that it does not understand. When a node encounters a mustUnderstand error, it should stop processing immediately (i.e., no further processing of other header blocks) and return the error. Also, this sentence might be construed to mean that the SOAP node MAY generate multiple faults. If my understanding is correct, then Example 6 should be changed to include only one Misunderstood header blocks. If not, then I would recommend that section 2.4 be changed to indicate that processing may continue after encountering a mustUnderstand fault.[email] |
|||||||
Proposal: | |||||||
Resolution:
After discussion, the WG has decided to close this issue without changes in the specification. The WG follows the remarks made by Noah Mendelson in [3] section #1.[email] |
|||||||
330 | spec | n/a | meta | Design | Closed | Mike Champion | |
Title: Contradiction in SOAP Process Model | |||||||
Description:
2.4 Understanding SOAP Headers, 3rd paragraph, last sentence "Tagging SOAP header blocks as mandatory thus assures that such modifications will not be silently (and, presumably, erroneously) ignored by a SOAP node to which the header block is targeted." This sentence implies that it will not be possible for modifications by mandatory header blocks to be silently and erroneously ignored. However, in the last 2 sentences of the next paragraph, it is said that "it is not an error for an ultimate SOAP receiver to receive a message containing a mandatory header block that is targeted at a role other than the ones assumed by the ultimate SOAP receiver. This is the case, for example, when a header block has survived erroneously due to a routing or targeting error at a preceding intermediary." That is, it is not an error for mandatory header block to survive erroneously and therefore be silently ignored, thus contradicting the first sentence quoted.[email] |
|||||||
Proposal: | |||||||
Resolution:
After discussion, the WG has decided to close this issue without changes in the specification. The WG follows the remarks made by Noah Mendelson in [3] section #2. In addition, your issue was discussed by the WG earlier named the "mustHappen" attribute. We desided to add no such attribute, because the same semantic could be embodied by adding SOAP header blocks. The mustUnderstand feature was carefully designed to support such requirements.[email] |
|||||||
331 | spec | n/a | meta | Design | Closed | Mike Champion | |
Title: URI Identification of MEPs | |||||||
Description:
(Part 1) Section 3.3 reads [2]: | In general the definition of a message exchange pattern: | * Is named by a URI. | * Describes the life cycle of a message exchange conforming to the | pattern. | * Describes the temporal/causal relationships of multiple messages | exchanged in conformance with the pattern. | * Describes the normal and abnormal termination of a message | exchange conforming to the pattern. This suggests that not all MEPs are identified by a URI. From an architectural point of view, and according to AR009.3[1], all conceptual elements should be addressable directly via a URI. We think that a URI should be required for MEPs: it is easy enough to assign one and will ease identification.[email] |
|||||||
Proposal: | |||||||
Resolution:
Per clarification of the specification (see resolution for LC Issue 230) an MEP as a feature must follow all the rules of the features and therefore MEPs are identified by URIs.[email] |
|||||||
332 | spec | n/a | meta | Design | Closed | Mike Champion | |
Title: External references? | |||||||
Description:
Section 2.6 reads [3]: "SOAP nodes MAY make reference to any information in the SOAP envelope when processing a SOAP body or SOAP header block. For example, a caching function can cache the entire SOAP message, if desired." We wonder about external references. They are not explicitely disallowed, but not referenced either. Needless to say, we think that external references are useful, e.g. to reference a large image that one doesn't want to carry along in the message.[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP WG has decided to close issue 332 you raised with no action taken. We have discussed external references in the past at some length, and determined their use should be application defined in most cases. Where external references are to attachments, we actively have work ongoing.[email] |
|||||||
333 | spec | n/a | meta | Design | Closed | Mike Champion | |
Title: QName vs URI | |||||||
Description:
Sections 5.4.1.3[4] and 5.4.6[5] use and define QNames to identify fault types, whereas WSAWG requirement AR009.3[1] calls for URIs. This is related to two open TAG issues: - Using Qualified Names (QNames) as Identifiers in Content[6]. - Algorithm for creating a URI from a QName[7].[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP WG decided to close issue 333 you raised with no action taken. We reviewed the TAG findings with regard to using QNames in a string [3] and determined our current specification is not in conflict with those findings. |
|||||||
334 | spec | n/a | Editorial | Design | Closed | Mike Champion | |
Title: Mention SOAP response MEP | |||||||
Description:
Part1 Section 2. SOAP Processing Model. First paragraph. It would be nice to mention the SOAP Response MEP. Also we don't find that section 3.3 SOAP Message Exchange Patterns (MEPs) really provides a description of the relationship between SOAP message exchange patterns and the SOAP extensibility model. It gives only a very brief definition of a MEP, and it makes no explicit mention of the extensibility model. It does describe the relationship between MEPs and the Protocol Binding Framework.[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP WG has decided to close this issue with no action: (i) The SOAP processing model is orthogonal to MEPs so there is no need to single out a particular MEP for mention in section 2. (ii) Whilst it would be possible to change the reference to section 3.3 to a more general reference to section 3, we prefer to maintain the more specific reference.[email] |
|||||||
335 | spec | n/a | Editorial | Design | Closed | Mike Champion | |
Title: Intermediaries remove blocks | |||||||
Description:
Section 2.7.2. Active Intermediaries. Second paragraph: Question. It says, "an active intermediary might have removed and encrypted some or all of the SOAP header blocks found in the inbound message". Shouldn't it say, "some or all of the SOAP header blocks and SOAP body"?[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP WG has decided to close this issue with no action since the text in question is only an example of the kind of modifications that intermediaries could make to a SOAP message. i.e. it does not preclude intermediaries from modifying the contents of the SOAP body.[email] |
|||||||
336 | spec | n/a | meta | Design | Closed | Mike Champion | |
Title: Length of URIs. | |||||||
Description:
I remember a somewhat long discussion on xml-dist-app about that and am still unsure about what we should say, but the following statement struck me [8]: | SOAP does not place any a priori limit on the length of a URI. Any | SOAP node MUST be able to handle the length of any URI that it | publishes and both SOAP senders and SOAP receivers SHOULD be able to | deal with URIs of at least 2048 characters in length. Even though the URI specification doesn't specify any limit on the length of a URI, the HTTP spec does provide a URI too long error code[9]. 2kB is identified here as a reasonable value to be able to handle. This seems to be an architectural issue, a Web services one as well as a Web one. I am afraid that such a statement will have a big impact on software designed. I think that I would be more comfortable by saying that software should be able to handle URIs of arbitrary length, and that a 2kB-length is seen _in SOAP's context_ as a minimum value to support.[email] |
|||||||
Proposal: | |||||||
Resolution:
The XML Protocol WG considered issue 336 today, an issue that you raised on the SOAP spec's statements about the length of URIs. Rather than having some statement containing overlapping SHOULDs (SHOULD support URIs of arbitrary length and SHOULD support URIs of length 2048), it was felt that the existing text already provided appropriate motivation for handling URIs of arbitrary length. Therefore, no change is being made to the specification.[email] |
|||||||
337 | spec | n/a | Editorial | Design | Closed | Mike Champion | |
Title: Editorial - (grammar & typos) - part 1 | |||||||
Description:
Editorial - part 1 Section 3.3. SOAP Message Exchange Patterns (MEPs) It would be nice to add a reference to Part 2, section 6. Section 4.2. Binding Framework. Third paragraph: ends with "one or more MEP". Should be "one or more MEPs". Section 5.2.1. SOAP header block. In the paragraph following Example 3, in the sentence, "A SOAP sender generating a SOAP message SHOULD use these attributes only on SOAP header block.": It should read, "only on a SOAP header block" Section 5.4.8. SOAP mustUnderstand Faults. First sentence. "When a SOAP node generates a fault with a Value of Code set to "env:MustUnderstand" for," -- delete the word "for". Section 7.3.1. Binding to Application-Specific Protocols. First paragraph, last sentence: "in order to reuse the existing infrastructure associated that protocol" should be "associated with that protocol".[email] |
|||||||
Proposal: | |||||||
Resolution:
With the exception of the first item, the WG has accepted your recommendations and made changes identical or similar to the ones you request. The workgroup did not decide to adopt the suggestion of a reference to Part 2 section 6 from part 1 section 3.3.[email] |
|||||||
338 | spec | n/a | meta | Design | Closed | Mike Champion | |
Title: state machine description questions | |||||||
Description:
(part 2) Question Section 6.2.3 State Machine Description, Table 6, Transition Condition, Init row If the Transition Condition is "Unconditional", then the boundary between Init state and the Requesting state is indistinguishable. Shouldn't the two states be one state? Question Section 6.2.3 State Machine Description, last bullet before 6.2.4 "A requesting SOAP node MAY enter the Fail state, and thus abort transmission of the outbound SOAP request, based on information contained in an incoming streamed SOAP response". In this case, should the responding SOAP node switch from generating a SOAP response to a SOAP fault ? Should the requesting SOAP node also generate a SOAP fault since it initated the transmission abortion?[email] |
|||||||
Proposal: | |||||||
Resolution:
The XML Protocol (XMLP) WG discussed and decided to close issue 338, which you originated, with the following resolutions: <Mike> Section 6.2.3 State Machine Description, Table 6, Transition Condition, Init row If the Transition Condition is "Unconditional", then the boundary between Init state and the Requesting state is indistinguishable. Shouldn't the two states be one state? </Mike> You are right. This is a bug. WG unanimously decided to change the transition condition, from 'Init' STATE to 'Requesting' STATE, to 'Transmission of request message initiated'. And, this change is in-sync with HTTP Binding. Where, 'Init' and 'Requesting' are distinct states and 'Transmission of request message initiated' is the transition condition. <Mike> Section 6.2.3 State Machine Description, last bullet before 6.2.4 "A requesting SOAP node MAY enter the Fail state, and thus abort transmission of the outbound SOAP request, based on information contained in an incoming streamed SOAP response". In this case, should the responding SOAP node switch from generating a SOAP response to a SOAP fault ? Should the requesting SOAP node also generate a SOAP fault since it initated the transmission abortion? </Mike> Close this issue with no action. Because, spec is correct and it outlines the following, * Requesting SOAP node does not issue a fault, just aborts and goes to fail state * Responding SOAP node goes to fail state, and sets context:FailureReason to "receptionFailure" * If context:FailureReason == fail:receptionFailure, then the responding node does not have to transmit any fault In general, responding SOAP node generates a SOAP fault if and only if the 'normal' soap rules say generate a fault. If it is a binding level fault, then the responding SOAP node generates a binding fault. If it is HTTP binding, Table 20 contains a list of HTTP Binding generated faults.[email] |
|||||||
339 | spec | n/a | Binding | Design | Closed | Mike Champion | |
Title: SOAP fault for Malformed Request Message | |||||||
Description:
(part 2) Question Section 7.5.2.1 Init, Table 20, SOAP Fault, Malformed Request Message row For Malformed Request Message ( HTTP Status Code 400, HTTP Reason: Bad request) the SOAP Fault is "None". Why not let the SOAP Fault to be "env:Sender", which is consistent with Table 23?[email] |
|||||||
Proposal: | |||||||
Resolution:
The specification is correct regarding the difference between Table 20 [2] and Table 23 [3]. Table 20 describes HTTP status codes corresponding to errors that can occur in the Init state. In this state no SOAP message has been received, and in accordance, the responding node must not send a SOAP fault as it don't know if there is a SOAP node at the other end. On the other hand, table 23 describes HTTP status codes corresponding to SOAP faults that might be generated by the responding SOAP node. Overall, some cleanup might make section 7.5.2 more clear. In accordance, the specification will be modified according to proposal in [4].[email] |
|||||||
340 | spec | n/a | Binding | Design | Closed | Mike Champion | |
Title: RPC Faults and HTTP status | |||||||
Description:
Question Section 7.5.2.2 Receiving, Table 23, SOAP Fault to HTTP Status Mapping What about mapping RPC Faults (see 4.4 RPC Faults) to HTTP Status? E.g. rule 2 in 4.4 defines a fault "env:DataEncodingUnknown" which is not mentioned in Table 23.[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP Working Group has closed Issue 340 with the following resolution: Add a new line into Table 23 [2] for the env:DataEncodingUnknown: SOAP Fault HTTP Status Code HTTP Reason Phrase env:DataEncodingUnknown 500 Internal server error The reason for choosing the 500 HTTP Status Code is to be consistent with the HTTP Status Code associated to env:VersionMismatch.[email] |
|||||||
341 | spec | n/a | Editorial | Design | Closed | Mike Champion | |
Title: part 2 - App A - UCS notation | |||||||
Description:
Section A.1 Rules for mapping application defined names to XML Names, Rule 5, case 4 "Let U1, U2, ... , U8 be the eight hex digits [PROD: 4] such that Ti is "U+" U1 U2 ... U8 in the UCS-4 encoding." The "U+" notation denotes the Unicode code point rather than either UCS-2 or UCS-4 encoding. Moreover, "the full range of Unicode code points [are] from U+0000 to U+10FFFF inclusive; code points above U+10FFFF MUST NOT be used". (See Character Model for the World Wide Web 1.0, 3.5 Reference Processing Model.) Suggest it be change to: "Let U1, U2, ... , U8 be the eight hex digits [PROD: 4] such that Mi is U1 U2 ... U8 in the UCS-4 encoding." Suggest also changing ' "This case implies that Ti has a UCS-2 encoding, which is U+U5U6U7U8." to: "This case implies that Ti has a UCS-2 encoding, which is U5U6U7U8."[email] |
|||||||
Proposal: | |||||||
Resolution:
In the email at [1] you raised on behalf of the WSAWG a set of issues, one of which the XML Protocols Workgroup identified as it's last call issue number 341. The issue related to the mapping of application-defined names to XML. The workgroup received other comments on this part of the specification, including a suggestion for substantial changes that we logged as issue 270 [3]. As described in the email closing issue 270 [4], a significant rewrite of the section in question has incorporated the suggestions we received in the two issues. Email [4] includes a reference to the revised text, which is in the editors draft of our specification.[email] |
|||||||
342 | spec | n/a | meta | Design | Closed | Mike Champion | |
Title: HTTP binding: interpretation of arbitrary HTTP status codes | |||||||
Description:
Section 7.5.1.2 Requesting[8] describes how a SOAP sender reacts to HTTP status codes returned by a SOAP receiver. Table 17[9] only lists a limited number of methods for which next states are listed. This seems to be contrary to the robustness principle cited in Part 1[10]. What would happen if the requestingSOAP node was receiving a 402 Payment Required[11] for example?[email] |
|||||||
Proposal: | |||||||
Resolution:
The XML Protocol (XMLP) WG has decided to close issue 342, which you originated, with the following resolution. Issue 342 is a DUPLICATE of issue 224 [2]. WG resolved issue 224 by adding the following paragraph to section 7.5.1.2 "Requesting" near Table 17, "Table 17 details the transitions that take place when a requesting SOAP node receives an HTTP status line and response headers. Table 17 refers to some but not all of the existing HTTP/1.1 [RFC 2616] status codes. In addition to these status codes, HTTP provides an open-ended mechanism for supporting status codes defined by HTTP extensions (see [RFC 2817] for a registration mechanism for new status codes). HTTP status codes are divided into status code classes as described in [RFC 2616], section 6.1.1. The SOAP HTTP binding follows the rules of any HTTP application which means that an implementation of the SOAP HTTP binding must understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response must not be cached"[email] |
|||||||
343 | spec | n/a | Editorial | Design | Closed | Mike Champion | |
Title: Editorial comments - Part 2 | |||||||
Description:
Editorial Section 5. A Convention for Describing Features and Bindings. First paragraph: "it is used to describe a Request-Response MEP 6.2 Request-Response Message Exchange Pattern and the SOAP HTTP Binding 7. SOAP HTTP Binding elsewhere in this document." It is also used to describe the the 6.4 Web Method Specification Feature feature and the 6.3 SOAP Response Message Exchange Pattern MEP, isn't it?[email] |
|||||||
Proposal: | |||||||
Resolution:
I am pleased to inform you that the XML Protocols workgroup has closed this issue by adopting your recommended changes.[email] |
|||||||
344 | spec | n/a | Editorial | Design | Closed | Mike Champion | |
Title: Primer - Definition of SOAP header | |||||||
Description:
(Part 0) 2.1. SOAP messages. The paragraph beginning with " A SOAP header". When I first read this paragraph, I was concerned with the implication that SOAP headers should be processed by a SOAP intermediary rather than by a SOAP header processor within a SOAP server. Then it dawned on me that perhaps the authors view a SOAP header processor as a SOAP intermediary. Rather than starting with a description that implies the use of an intermediary, I think the paragraph should start with a basic definition of a SOAP header: A SOAP header is an extension mechanism that provides a way to pass information that isn't application payload. Then it should discuss why you might want to use this information (to pass control, directive, or contextual information) and how to insert header processors into the SOAP processing scheme (either as intermediaries or as header processors called by a SOAP server). Or it might simply make it obvious to the reader that a SOAP header processor is in fact a SOAP intermediary.[email] |
|||||||
Proposal: | |||||||
Resolution:
This comment has been incorporated into the editor's copy of the Primer[email] |
|||||||
345 | spec | n/a | Editorial | Design | Closed | Mike Champion | |
Title: Primer: omission in example 2? | |||||||
Description:
2.2.1. Document-style message exchange. Example 2. Shouldn't the returned <p:airportChoices> element contain an enumeration?[email] |
|||||||
Proposal: | |||||||
Resolution:
The schema document (not shown in the Primer, but implied and tangentially mentioned in the text following example 2), of which example 2 is an instance, would show that the element "airportChoices" is a list type (xsd:list). Hence the instance document - example 2 - lists the airport choices. So no changes are necessary to example 2.[email] |
|||||||
346 | spec | n/a | Editorial | Design | Closed | Mike Champion | |
Title: RPC and "Web-friendly" discussion in Primer | |||||||
Description:
2.2.2. Remote procedure calls. This discussion about RPC makes the assumption that it will use the HTTP protocol, and hence spends a great deal of time up front discussing "Web-friendly" concepts before discussing the basics of the the RPC convention. I also find the tone to be somewhat defensive -- It sounds as if it's trying to convince me that this is the right way to do it (and that I have another choice). I much prefer the way this information is presented in Part 2, Section 4 [12]. It's very straight-forward and direct. It says -- this is the way you do RPCs (articulating how it maps to the two MEPs), and when you're using HTTP as a transport, you need to use the Web Method Feature. The GET Web Method is the preferred mechanism to implement SOAP-based idempotent information retrieval. Since the RPC convention isn't dependent on HTTP, I'd recommend: 1) it be explicitly stated right up front (Part 2, section 4 describes it in terms of RPC invocations and responses mapping naturally to HTTP requests and responses, but that RPC is not dependent on HTTP). 2) most of the Web-friendly discussion (The paragraphs starting with "Items 4 and 5" through "We defer until section 3") be moved to section 3 with appropriate references to that section made in this section.[email] |
|||||||
Proposal: | |||||||
Resolution:
The main point in all these comments, that section 2.2.2 should only deal with the syntactical aspects of encapsulating rpcs and that the web-friendly discussion should be moved to section 3.1, has been accepted and incorporated into the latest editor's copy of the Primer.[email] |
|||||||
347 | spec | n/a | Editorial | Design | Closed | Mike Champion | |
Title: Primer - RPC invocation | |||||||
Description:
(related to 347) 2.2.2. Remote procedure calls. Point #4. Is this "information needed to invoke a SOAP RPC"? Isn't this a clarification of how the information described by points 2 and 3 must be specified? I understand that we want to explain Web-friendly RPCs, but I don't think this point belongs in this list. I think it belongs in the follow-on text with appropriate references to section 3.1.1. I would therefore recommend a change to the following two paragraphs to first assert the requirement to clearly separate the arguments used to identify the target Web resource from the arguments used to convey data or control information and then to explain why. We should promote the Web-friendly way as the preferred way to implement information-retrieval requests, as specified in Section 3.1.3.)[email] |
|||||||
Proposal: | |||||||
Resolution:
Regarding the points made in Issue 347 and 348 about items 4, 5 in section 2.2.2, no changes have been made to these items, as they are essentially the same as that provided in SOAP part 2 (although written somewhat more informally). Specifically, the web method feature (item#5) is available to all bindings, and not just the HTTP one, although that is the usage that is standardized at this time.[email] |
|||||||
348 | spec | n/a | meta | Design | Closed | Mike Champion | |
Title: Primer - RPC - point only valid when using HTTP | |||||||
Description:
2.2.2. Remote procedure calls. Point #5. This point is only valid when using HTTP. Per Part 2, Section 4, this point should read: "Values for properties as required by any features of the binding to be used. For example, GET or POST for the webmeth:Method property of the 6.4 Web Method Specification Feature."[email] |
|||||||
Proposal: | |||||||
Resolution:
Regarding the points made in Issue 347 and 348 about items 4, 5 in section 2.2.2, no changes have been made to these items, as they are essentially the same as that provided in SOAP part 2 (although written somewhat more informally). Specifically, the web method feature (item#5) is available to all bindings, and not just the HTTP one, although that is the usage that is standardized at this time.[email] |
|||||||
349 | spec | n/a | meta | Design | Closed | Mike Champion | |
Title: Primer - RPC - add a reference to HTTP? | |||||||
Description:
2.2.2. Remote procedure calls. The paragraph starting with "Items 4 and 5": There should be a reference to HTTP in this paragraph (rather than just referring to the World Wide Web). This paragraph should be moved to section 3.[email] |
|||||||
Proposal: | |||||||
Resolution:
The sentence referred to in Issue 349 has been deleted, as similar sentences already appear in section 3.1.3.[email] |
|||||||
350 | spec | n/a | Editorial | Design | Closed | Mike Champion | |
Title: Editorial (grammar & typos) - Primer | |||||||
Description:
1. Introduction. Last sentence of the paragraph starting with "Part 2". I don't think this sentence belongs here. (No other part of this first Introduction section gets into this much detail.) I'm concerned by the implication that SOAP isn't "Web-friendly". At the very least, if the term is introduced here, there must be a definition provided with it. I think the topic is properly covered as part of the introduction in 1.1 Overview section in the paragraph starting with Section 3. 2.2.2. Remote procedure calls. In the paragraph starting with "The central role": This paragraph should be moved to section 3. A space is required here: "Part 2 Section 4.1.1provides" also "data that is necessary" should be "data that are necessary" 2.2.2. Remote procedure calls. Example 4: For readability, here should be a line break between the elements in this line: </m:reservation> <o:creditCard xmlns:o="http://mycompany.example.com/financial"> and this line: </n:name> <o:number>123456789099999</o:number> 2.2.2. Remote procedure calls. Third paragraph from the end, starting with "While in principle": "inependent" is misspelled. 2.4. SOAP processing model. Second paragraph: "(with their contents elided for brevity)" -- we might want to use a more well-known term than "elided" -- perhaps "removed" or "edited". 2.4. SOAP processing model. eleventh paragraph, starting "If a header element": "content is data" should be "contents are data". 2.4. SOAP Processing model. The paragraph starting with "The following table": "appropriate" should be "appropriately". 3. Using various protocol bindings. The paragraph starting with "Thus it is apparent": The phrase "accomplish a particular application semantics" (which appears twice in this paragraph) should be either "accomplish particular application semantics" or "accomplish a particular application semantic". 3. Using various protocol bindings. The paragraph starting with "Among other things": The last sentence reads, "a non-SOAP message acting as a response followed by a SOAP message included as a part of the response" should say, "a non-SOAP message acting as a request followed by a SOAP message included as a part of the response". 3. Using various protocol bindings. The paragraph starting with "Part 2 section 7specifies": A space is required here: "Part 2 section 7specifies" 3.1. HTTP binding. Last sentence of the paragraph starting with "The purpose of providing": "Acceptheader" should be "Accept header" 3.1.1. SOAP HTTP Get usage. The second paragraph, beginning with "Example 8a shows": A space is required here: "URIhttp://travelcompany.example.org/reservations?code=FT35ZBQ" 3.1.1. SOAP HTTP Get usage. The third-to-last paragraph starting with "In Example 8b" "outboundandreturn" shoudl be "outbound and return". 3.1.2. SOAP HTTP POST usage. Example 9: For readability, a line should be inserted between the elements here: </m:reservation> <o:creditCard xmlns:o="http://mycompany.example.com/financial"> and here: </n:name> <o:number>123456789099999</o:number> 3.1.2. SOAP HTTP POST usage. In the paragraph betwee Example 9 and Example 10. "Example 10 shows the RPC return (with details elided)" -- again I recommend using a more common word than "elided". 3.1.2. SOAP HTTP POST usage. Last paragraph. Are we using American or English spelling? Should "behaviour" be "behavior"? 3.1.3. Conveying Web-friendly RPCs. In the paragraph just before Example 12b, starting with "Furthermore": The sentence "SOAP 1.2 recommends that the SOAP Response message exchange pattern be used as described in section 3.1.2." should refer to section 3.1.1. 3.1.3. Conveying Web-friendly RPCs. In the paragraph just before Example 13, starting with "Example 13": "thenameof" should be "the name of" and "Bodyelement" should be "Body element". 3.2. SOAP over email. In the paragraph starting with "Example 15": I recommend using a more commonly known word than "elided". Also a space is required in "email'sMessage-Id". 5. Changes between SOAP 1.1 and SOAP 1.2. Under "Document structure", first bullet: "strucure" should be "structure".[email] |
|||||||
Proposal: | |||||||
Resolution:
This comment has been incorporated into the editor's copy of the Primer[email] |
|||||||
351 | spec | n/a | Editorial | Design | Closed | Susan Lesch | |
Title: Editorial (typos) - All docs | |||||||
Description:
This is only an editorial comment and I hope in time to help. A spell checker found minor errors. Twice in each of the four drafts, Mitre should read MITRE. In Assertions and Test Collection http://www.w3.org/TR/2002/WD-soap12-testcollection-20020626 s/existant/existent/ s/indetifier/identifier/ s/charater/character/ s/attibute/attribute/ s/concatanate/concatenate/ s/secound/second/ s/paramenter/parameter/ s/childern/children/ In Part 0: Primer http://www.w3.org/TR/2002/WD-soap12-part0-20020626/ s/analyse/analyze/ s/targetted/targeted/ s/ancilliary/ancillary/ knowna priori should read known a priori In Part 1, nothing but MITRE to report In Part 2: Adjuncts http://www.w3.org/TR/2002/WD-soap12-part2-20020626/ s/performingsimilar/performing similar/[email] |
|||||||
Proposal: | |||||||
Resolution:
Thanks for your edits on SOAP Part 0: Primer, identified as LC Issue #351. They have been included for the next revision of the Primer WD.[email] |
|||||||
352 | spec | n/a | Editorial | Design | Closed | Micah Dubinko | |
Title: Editorial - All docs | |||||||
Description:
[Throughout] When referring to XML Schema datatypes, please use the more compact notation 'xs:anyURI' instead of 'anyURI in the namespace named "http://www.w3.org/2001/XMLSchema"' [Throughout] Please use textual instead of numeric identifiers for references ( [HTTP 1.1] instead of [2]) This applies to parts 0-2. [Part1 8. References] The following reference seem to be "orphaned" (not referred to from anywhere) [9] (XLink) Please remove the reference. [Throughout] Please ensure that infoset property names and values have a distinguishing typographical style. (Example: "A specified property..." should be "A [specified] property...")[email] |
|||||||
Proposal: | |||||||
Resolution:
This comment has been incorporated into the editor's copy of the Primer[email] |
|||||||
353 | spec | n/a | Editorial | Design | Closed | Micah Dubinko | |
Title: Editorial - Readabilituy comments - part 2 sections 2/3 | |||||||
Description:
n) [Part2 2.1 Graph Edges & 2.2 Graph Nodes] In the above sections, please provide an examples of non-XML data structures, such as a 'struct' and 'array' from a programming language, and how these map to abstract nodes and edges, or alternately include a hyperlink to such examples in a separate document. o) [Part2 3.1.1 Encoding graph edges and nodes & 3.1.2 Encoding simple values & 3.1.3 Encoding compound values & 3.1.4 Computing the Type Name property & 3.1.5 Unique identifiers & 3.1.6 arraySize Attribute Information Item] For each of the above sections, please include at least one example, or alternately include a hyperlink to an example in a separate document. p) [Part2 3.1 Rules for encoding Graphs in XML] "The encodings are described below from the perspective of a de-serializer." Not only does this point of view conflict with the section name, it also makes understanding the encoding unnecessarily difficult. Please re-write this section from the point of view of an XML serializer. q) [Part2 3.1.1 Encoding graph edges and nodes] The first sentence of this section is strongly worded, and suggests that element information items *only* represent edges, when in fact they at times represent a combined edge and node. (for example in the first sentence of 3.1.3) Please correct this. Bullet 4 mentions "a graph edge [that] does not terminate in a graph node". This is confusing, and seemingly in conflict with the first sentence in 2.1: " Edges in the graph are said to originate at a graph node and terminate at a graph node."[email] |
|||||||
Proposal: | |||||||
Resolution:
Here is a brief summary of our decisions regarding your individual suggestions: >> n) [Part2 2.1 Graph Edges & 2.2 Graph Nodes] >> In the above sections, please provide an examples of non-XML data >> structures, such as a 'struct' and 'array' from a programming language, and >> how these map to abstract nodes and edges, or alternately include a >> hyperlink to such examples in a separate document. Our general intention has been to minimize the inclusion of tutorial material in the normative portion of the specification. In addition, we note that the recommendation does not in fact define a mapping from programming languages, but only from an abstract data model. Finally, we generally try to avoid examples involving particular programming languages, as it is difficult to avoid implicitly supporting or undermining the interests of various member organizations that base their investments on particular programming languages or technologies. Accordingly, we respectfully decline this suggestion. >> o) [Part2 >> 3.1.1 Encoding graph edges and nodes & >> 3.1.2 Encoding simple values & >> 3.1.3 Encoding compound values & >> 3.1.4 Computing the Type Name property & >> 3.1.5 Unique identifiers & >> 3.1.6 arraySize Attribute Information Item] >> For each of the above sections, please include at least one example, or >> alternately include a hyperlink to an example in a separate document. Here too, we respectfully decline to include examples in the normative parts of the recommendation. >> p) [Part2 3.1 Rules for encoding Graphs in XML] >> "The encodings are described below from the perspective of a de-serializer." >> Not only does this point of view conflict with the section name, it also >> makes understanding the encoding unnecessarily difficult. Please re-write >> this section from the point of view of an XML serializer. I was involved, along with one other editor, in drafting this section. Our original approach was indeed to adopt the perspective of the serializer. In fact, this proved extremely difficult, and the current formulation proved much more straightforward. Though there are a number of subtleties, the essence of the reason is that there is a 1-to-many relationship of graphs to encodings: the same graph can in general be represented many ways (for example, the placement in the xml of targets of a ref= attribute is in many cases not significant. Conversely, each serialized encoding represents exactly one graph. Accordingly, we start with a serialization and say essentially "this is THE graph it represents". We then say in effect "to serialize a graph, you can use any of the representations the decode to the correct graph." We agree that the title of the section was misleading, and have therefore in response to your suggestion we have renamed it: "Mapping between XML and the SOAP Data Model". >> q) [Part2 3.1.1 Encoding graph edges and nodes] >> The first sentence of this section is strongly worded, and suggests that >> element information items *only* represent edges, when in fact they at times >> represent a combined edge and node. (for example in the first sentence of >> 3.1.3) Please correct this. As you suggest, the text in section 3.1.1 has been updated [3]. It now reads: "1. If the element information item representing the edge does not have a ref attribute information item (see 3.1.5.2 ref Attribute Information Item) among its attributes then that element information item is said to represent a node in the graph and the edge terminates at that node. In such cases the element information item represents both a graph edge and a graph node." >> Bullet 4 mentions "a graph edge [that] does not terminate in a graph node". >> This is confusing, and seemingly in conflict with the first sentence in 2.1: >> " Edges in the graph are said to originate at a graph node and terminate at >> a graph node." In closing issue 302 [4], the workgroup has verified its decision that edges can be "dangling" at either the source or the destination end. The note resolving that issue is at [5], and it includes a statement of our intention to: "close this issue by adding the following text to Section 2.1 [6] {<== reference number changed...NRM} "An edge MAY have only an originating graph node, that is be outbound only. An edge MAY have only a terminating graph node, that is be inbound only."[email] |
|||||||
354 | spec | n/a | Editorial | Design | Closed | Micah Dubinko | |
Title: Part 0 - clarifications on terms | |||||||
Description:
a) [Part0 3. Using various protocol bindings] "...an encrypted form." Can you clarify in the text whether you mean 'a fill-out form' vs. "the mode in which a thing exists"? [dictionary.com] b) [Part0 3.1.1. SOAP HTTP GET usage] Please mention that to use an XML SOAP envelope as XForms external instance data, HTTP GET usage (SOAP Response Message Exchange Pattern) is required. At the editors' discretion, you might also mention other similar cases, such as document() in XSLT, etc.[email] |
|||||||
Proposal: | |||||||
Resolution:
Comment a) has been incorporated into the editor's copy of the Primer[email] |
|||||||
355 | spec | n/a | Encoding | Design | Closed | Micah Dubinko | |
Title: May a SOAP infoset legally contain comment information items? | |||||||
Description:
c) [Part1 5. SOAP Message Construct] May a SOAP infoset legally contain comment information items? If yes, where? Please clarify.[email] |
|||||||
Proposal: See Gudge's proposal | |||||||
Resolution:
The WG resolved this by saying that comments are allowed anywhere in the [document element] but not before or after that element. There are some restrictions in the processing model WRT when comments can be added and/or removed. [2].[email] |
|||||||
356 | spec | n/a | meta | Design | Closed | Micah Dubinko | |
Title: SOAP Body child Element namespace qualified | |||||||
Description:
d) [Part1 5.3.1 SOAP Body child Element] Child elements "MUST have a [namespace name] property which has a value, that is, be namespace qualified." We request removing this restriction for the following reason: Many XML Forms use non-namespaced instance data, and we expect SOAP to become a common source of instance data for such Forms. Thus, a requirement for namespaces would put an unnecessary burden on adoption of both SOAP and XForms.[email] |
|||||||
Proposal: | |||||||
Resolution:
The XML Protocol WG has decided to close issue 356 by changing the MUST requirement for namespace qualification of SOAP Body content to a SHOULD with a descriptive note explaining the reason for the SHOULD. The resolution text which will be applied to Part1 5.3.1 "SOAP Body child Element" is the following: * * * * * Zero or more information items in its [children] property. Child element information items SHOULD be namespace qualified. NOTE: namespace qualified elements tend to produce messages whose interpretation is less ambiguous than those with unqualified elements. The use of unqualified elements is therefore discouraged. * * * * *[email] |
|||||||
357 | spec | n/a | Editorial | Design | Closed | Micah Dubinko | |
Title: Fault names | |||||||
Description:
e) [Part1 5.4.6 SOAP Fault Codes] Please change the name of the "DataEncodingUnknown" fault code to the more accurate "SOAPEncodingUnknown". f) [Part1 5.4.8 SOAP mustUnderstand Faults] The name "Misunderstood" suggests that the processor incorrectly attempted to do something. "NotUnderstood" is a more accurate name.[email] |
|||||||
Proposal: | |||||||
Resolution:
For e) we chose to maintain the name "DataEncodingUnknown" as "SOAPEncoding" can be misunderstood to refer to the specific encoding provided in SOAP 1.2 part 2. The fault code in question can be used with any encoding scheme used. For f) we agreed with the proposal and changed the name to "NotUnderstood".[email] |
|||||||
358 | spec | n/a | meta | Design | Closed | Micah Dubinko | |
Title: URI length | |||||||
Description:
g) [Part1 6. Use of URIs in SOAP] "SOAP receivers SHOULD be able to deal with URIs of at least 2048 characters in length" We request that this be a MUST requirement.[email] |
|||||||
Proposal:
Gudge's proposal: this is a duplicate of closed issue 336. See Henrik's proposal |
|||||||
Resolution:
The XMLP WG has decided to close issue 358 without taking any action. This was a duplicate of issue 336 [2], the resolution text was: <_336> The XML Protocol WG considered issue 336 today, an issue that you raised on the SOAP spec's statements about the length of URIs. Rather than having some statement containing overlapping SHOULDs (SHOULD support URIs of arbitrary length and SHOULD support URIs of length 2048), it was felt that the existing text already provided appropriate motivation for handling URIs of arbitrary length. Therefore, no change is being made to the specification. </_336> Quoting directly from an email[3] on the xml-dist-app list: <furtherReasoning> 1) We don't enforce any max number of URIs to be used in a SOAP message which could then be interpreted as saying that we require infinite buffering on a SOAP node. 2) Related to 1), we don't enforce any max size on a SOAP message itself 3) The current text makes it clear that "Any SOAP node MUST be able to handle the length of any URI that it publishes" so we do have a MUST requirement for any given SOAP node. </furtherReasoning>[email |
|||||||
359 | spec | n/a | meta | Design | Closed | Micah Dubinko | |
Title: SOAP 1.1 to 1.2 transition non normative section | |||||||
Description:
h) [Part1 A. Version Transition From SOAP/1.1 to SOAP Version 1.2] This section states that SOAP nodes receiving SOAP/1.1 messages either: 1 "MAY process the message as a SOAP/1.1 message (if supported), or" 2 "MUST generate a version mismatch SOAP fault based on a SOAP/1.1 message construct following SOAP/1.1 semantics." Either way, a reference to SOAP/1.1 ([19] in the current document) is required. Since that appendix is not specifically marked "non-normative", the reference would have to be normative, and thus all conforming SOAP/1.2 processors also must implement a portion of SOAP/1.1. Please ensure that conformance to this section of SOAP/1.1 is considered a "feature" for purposes of exit criteria.[email] |
|||||||
Proposal: See email, and email. | |||||||
Resolution:
At the SOAP WG F2F meeting on October 30th, the WG agreed to resolve issue 359 by adopting the text in http://lists.w3.org/Archives/Public/xml-dist-app/2002Oct/0170.html[email] |
|||||||
360 | spec | n/a | meta | Design | Closed | Micah Dubinko | |
Title: Modularization - separate docs | |||||||
Description:
i) [Part2 Sections 2-4 & Appendix A (re: SOAP encoding and RPC Representation)] We request that these optional sections be moved into a separate document. We note the success with which XHTML, SVG, CSS, and XPointer have done similar modularization. As written, these optional sections contain optional subsections (and even required subsections), which is unnecessarily complex. As a separate document, the conformance requirements for RPC SOAP can be more clearly spelled out, and the result will be smaller, simpler SOAP specifications.[email] |
|||||||
Proposal: Gudge's proposal:
This issue is a duplicate of earlier issue 198[2]. I propose we close it with no action. |
|||||||
Resolution:
The XMLP WG decided to close issue 360 which you raised with no action taken as this issue is a duplicate of issue 198 [2], which was closed before last call [3].[email] |
|||||||
361 | spec | n/a | Editorial | Design | Closed | Micah Dubinko | |
Title: Part 2 - Change ItemType AII to childItemType | |||||||
Description:
j) [Part2 2.3 Values] We agree with the editorial note which suggests removing "generics". k) [Part2 3.1.4.1 itemType Attribute Information Item] Please change the name of this to "childItemType".[email] |
|||||||
Proposal: | |||||||
Resolution:
The specific requests that we included in this issue, and their resolution are: > j) [Part2 2.3 Values] > We agree with the editorial note which suggests removing "generics". The workgroup has decided to accept your suggestion and remove generics from the design. The only compound values supported will be arrays and structs. > k) [Part2 3.1.4.1 itemType Attribute > Information Item] Please change the > name of this to "childItemType". The members of the XML protocol workgroup have decided that itemType is on balance a better name, and have therefore decided not to adopt your suggestion in this area.[email] |
|||||||
362 | spec | n/a | meta | Design | Closed | Micah Dubinko | |
Title: ref/ifref (part 2) | |||||||
Description:
l) [Part2 3.1.5.2 ref Attribute Information Item] Please change the name of this to "idref". This not only more closely represents the type of the attribute (xs:IDREF), but also avoids cognitive dissonance with the XForms attribute 'ref' (which bears an XPath expression). m) [Part2 3.2 Decoding Faults] id->idref constraint violations are serious problems. Please change 'SHOULD' to 'MUST' on the requirement to signal a fault under these conditions.[email] |
|||||||
Proposal:
Gudge's proposals:
for 1 st partsecond part:
If we decide to close issue 326 by qualifying attribute I think part A of this issue can be closed with no action as the XForms ref attribute is unqualified ( and ours will then be qualified ). If we do decide to leave our ref attribute unqualified then we should probably think about changing the name. I propose that we close part b of this issue with no action. The id/idrefs in question are those found in SOAP encoding. The rule does not apply to general ID/IDREFs. In fact, we can't detect general ID/IDREF without schema validation, which is optional anyway. |
|||||||
Resolution:
We divided the issue into two related parts: Part I: "l) [Part2 3.1.5.2 ref Attribute Information Item] The Protocols Workgroup has recently decided to add namespace qualification to all of our attributes, and in particular to the attribute formerly known as "ref". We believe that the resulting qualified attribute is sufficiently distinct as to not cause confusion with XForms. In general, we name our attributes by their purpose, not their type, and so respectfully decline to use IDREF as the localname of the attribute. Part II: "[Part2 3.2 Decoding Faults] We note that SOAP processing never depends on validation [3]: "SOAP does not require that XML Schema processing (assessment or validation) be performed to establish the correctness or 'schema implied' values of element and attribute information items defined by this specification." Indeed, the soapenc:ref and soapenc:id attributes (the new names) are provided for SOAP's own purposes. We note further that there are many reasonable situations in which checking for a match of id and idref might be inappropriate. For example, the application might determine, perhaps by processing a header, that it has no need to inspect the encoded data at all. Making the check a MUST would require the node to check the ID/IDREF pairs, regardless of whether the data is needed by the application. We therefore believe that SHOULD is the best description of our intent, which is that in most cases the correctness of the reference should be checked. In any case, we specifically decline to associate such checking with a need to do XML Schema or DTD validation: such validation is allowed as if the application so desires, but is never required and is considered non-normative. [4][email] |
|||||||
363 | spec | n/a | meta | Design | Closed | Robert Van Engelen | |
Title: RPC return accessor | |||||||
Description:
1. It is our opinion that the SOAP RPC return value accessor is ambiguous and imposes unnecessary processing complexities. For details on this issue, please refer to earlier message[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP WG has decided to close issue [1] "RPC return accessor" without taking any action. This issue has been subsumed by the fact that we have dropped the RPC array representation [2].[email] |
|||||||
364 | spec | n/a | meta | Design | Closed | Robert Van Engelen | |
Title: id and ref emutually xclusive | |||||||
Description:
Section 3.1.5.3 in "SOAP 1.2 Adjuncts" forbids id and ref attribute information items to appear in the same element information item. It is our opinion that this constraint unnecessarily limits the object graph data model. The resulting admissible data model does not allow for "pointer chain" graphs. Details can be found in earlier message[email] |
|||||||
Proposal: see email | |||||||
Resolution:
The XMLP WG has decided to close issue 364 (that you raised about id and ref attributes being mutually exclusive) with no changes to the specification. The rationale is explained in [2].[email] |
|||||||
365 | spec | n/a | meta | Design | Closed | Robert Van Engelen | |
Title: Generics | |||||||
Description:
To comment on the Editor's request for comments on "generics": It is our opinion that generics should be kept in the specification. Generics are useful mainly from a practical point of view because generics do not widen the gap between SOAP RPC and SOAP DOC/LIT data models. We believe that abolishing generics only widens this data modeling gap, thereby unnecessarily limiting the expressiveness of the data model of SOAP RPC.[email] |
|||||||
Proposal: | |||||||
Resolution:
You also asked that generics be kept in the SOAP specification. The XMLP WG earlier decided to close Issue 297 by removing generics. The entire rationale for removing generics is available at [1], but an abreviated version is given here for ease of access. Essentially, the XMLP WG is of the opinion that generics are unnecessary in the Data Model. The issue was discussed among the implementors and among the xml-dist-app community without reaching any obvious consensus. In addition, feedback was asked by an ednote in Part 2, Section 2.3. The prevalent feedback was that generics be removed. Finally, XMLP WG implementors have confirmed they would welcome removing generics (with the exception of WebMethods, which prefered to keep generics but did not oppose the decision).[email] |
|||||||
366 | spec | n/a | meta | Design | Closed | Robert Van Engelen | |
Title: Generic type for struct and array | |||||||
Description:
We do not oppose the array representation of SOAP RPC invocation. However, we do strongly suggest the use of generic types to support both struct and array parameter paradigms. In fact, it is our opinion that generics should be the ONLY parameter marshalling type. In that way, polymorphic remote methods and remote methods with variable number of parameters can be supported, while providing a similar functionality as parameter marshallings based on structs and arrays.[email] |
|||||||
Proposal: | |||||||
Resolution:
You asked that SOAP 1.2 include a generic type for structs and arrays. The XMLP WG earlier decided to close Issue 297 by removing generics. The entire rationale for removing generics is available at [1], but an abreviated version is given here for ease of access. Essentially, the XMLP WG is of the opinion that generics are unnecessary in the Data Model. The issue was discussed among the implementors and among the xml-dist-app community without reaching any obvious consensus. In addition, feedback was asked by an ednote in Part 2, Section 2.3. The prevalent feedback was that generics be removed. Finally, XMLP WG implementors have confirmed they would welcome removing generics (with the exception of WebMethods, which prefered to keep generics but did not oppose the decision).[email] |
|||||||
367 | spec | n/a | meta | Design | Closed | Kirill Gavrylyu | |
Title: QA - Scope of the spec. | |||||||
Description:
There is no dedicated section that would explain what is in scope and what is explicitly left out of scope of the specification.[email, report] |
|||||||
Proposal: See email and following thread | |||||||
Resolution:
Issue 367, we have introduced a Conformance section as requested, see [1].[email |
|||||||
368 | spec | n/a | meta | Design | Closed | Kirill Gavrylyu | |
Title: QA - Conformance section | |||||||
Description:
There is no dedicated Conformance section that would o Define what is the object of the spec (SOAP Processor) and what is it. o when an implementation could claim conformance to the SOAP 1.2 spec, and what does it mean. o clearly state that Part I is obligatory and any adjunct from the Part II is optional. What combinations of the adjuncts in Part II are allowed. o State explicitly, does the implementation of the Part I that does not use any of the adjunct of the Part II still conform to the SOAP 1.2 specification.[email, report] |
|||||||
Proposal: See email and following thread | |||||||
Resolution:
Issue 368, within the new conformance section: -- we describe what constitutes (the scope of) an implementation, see also "SOAP node" in the glossary [4]. -- we say when an implementation can say it conforms -- we clarify the requirements for implementing Parts 1 and 2[email |
|||||||
369 | spec | n/a | meta | Design | Closed | Kirill Gavrylyu | |
Title: QA - Not clear if the implementation is required to implement any of the adjuncts from the Part 2 | |||||||
Description:
Embedded in the issue 368. Not clear if the implementation is required to implement any of the adjuncts from the Part 2 in order to conform to the SOAP 1.2 specification.[email, report] |
|||||||
Proposal: See email and following thread | |||||||
Resolution:
Issue 369, covered under resolution of #368[email |
|||||||
370 | spec | n/a | meta | Design | Closed | Kirill Gavrylyu | |
Title: QA - No definition of SOAP Processor | |||||||
Description:
Embedded in the issue 368. Not defined what can be called a "SOAP Processor".[email, report] |
|||||||
Proposal:
Proposal: The term "SOAP processor" is a leftover from old terminology and should be changed to "SOAP node". It occurs in the status section of part 1 and throughout part 2.[email] |
|||||||
Resolution:
The XMLP WG has decided to close issue 370 with a text change. As you pointed out "SOAP processor" is not defined. The term "SOAP processor" is a leftover from old terminology and will be changed to "SOAP node" throughout Part 1 and Part 2.[email] |
|||||||
371 | spec | n/a | meta | Design | Closed | Kirill Gavrylyu | |
Title: QA - Multiple Choice Assertions | |||||||
Description:
For some of the multiple-choice assertions, it is not explicitly defined whether the choice must be consistent by the SOAP Node or not. For example, in the section 2.4, assertion regarding mustUnderstand SOAP headers that allows to either process the Header marked as MustUnderstand or generate a Fault message. It is not clear under which circumstances the behavior of the SOAP Node MUST remain consistent.[email, report] |
|||||||
Proposal: See proposal and following thread. | |||||||
Resolution:
The XMLP WG decided to close issue 371 you raised by adding a sentence to section 2.6 of Part 1. Original Text: "In all cases where a SOAP header block is processed, the SOAP node MUST understand the SOAP header block and MUST do such processing in a manner fully conformant with the specification for that header block." Modified Text: "In all cases where a SOAP header block is processed, the SOAP node MUST understand the SOAP header block and MUST do such processing in a manner fully conformant with the specification for that header block. The successful processing of one header block does not guarantee successful processing of another block with the same fully qualified name within the same message: the specification for the header block determines the circumstances in which such processing would result in a fault."[email] |
|||||||
372 | spec | n/a | Editorial | Design | Closed | David Costanzo | |
Title: Typographical comments on "SOAP Version 1.2 Part 0: Primer" | |||||||
Description:
The following comments apply to the document at: http://www.w3.org/TR/soap12-part0/ This seems to be more recent the "editor's latest draft". However, many of the typos are in both documents. There are several inconsistent uses of the article "a" and "an" when they precede acronyms or abbreviations that begin with a vowel sounding letter. * There are about ten instances of "a RPC" and three instances of "an RPC". To me, "an RPC" reads better. * There are four instances of "a URI" and one instance of "an URI". To me, "a URI" reads better. * There is one instance of "an URL". To me, "a URL reads better". Section 2.2.2. In the phrase "... where the purpose appear to be ...", "appear" should be changed to "appears". Section 2.2.2. In the phrase "... the RPC response is returned in the body element of a SOAP message, with is modelled as a ...", "with" should be "which". Section 2.2.2. In the phrase "... which is an enumeration with potential values of 'confirmed', and 'pending' ...", the comma just before "and" should be removed. Section 2.2.2. In the phrase "... thereby making the RPC inependent of any underlying transfer mechanism.", the word "inependent" should be corrected to "independent".[email] |
|||||||
Proposal: | |||||||
Resolution:
This comment has been incorporated into the editor's copy of the Primer[email] |
|||||||
373 | spec | n/a | Editorial | Design | Closed | Martin Duerst | |
Title: Character Model - text normalization | |||||||
Description:
At our editorial meeting last week, the I18N WG realized that some important points were missing from our last call review of SOAP 1.2. In the last call review of the Character Model by the XML Protocol WG, the XML Protocol WG and the I18N WG/IG have been discussing how text normalization should apply to SOAP. For a compact summary of the decisions arrived, see: http://www.w3.org/International/Group/2002/charmod-lc/#C062 However, we have not found any text in the SOAP specs that says that the envelope/headers have to be normalized, nor that it is the responsibility of the payload provider to provide a suitably normalized payload.[email] |
|||||||
Proposal: | |||||||
Resolution:
The SOAP WG has decided to close issue 373 - Normalisation of text in envelope/header/body. Previous discussions with I18N led the SOAP WG to decide that we would not require normalization of text. See the discussion at http://www.w3.org/International/Group/2002/charmod-lc/#C062[email] |
|||||||
383 | spec | n/a | meta | Design | Closed | Hervé Ruellan | |
Title: Part 2 - Table 17 discrepancies | |||||||
Description:
While reading Section 7.5.1 [1] and Section 7.5.2 [2] of part 2, it seems that Table 17 [3] is not fully in sync with what the SOAP receiver might generate. A SOAP receiver might generate a 400 HTTP Status code either in its Init state or in its Receiving state. In the first case, the HTTP response contains no SOAP fault and accordingly, the SOAP requestor should transition to the Fail state, while in the second case, the HTTP response may contain a SOAP fault and if this is the case, the SOAP requestor should transition to the Sending+Receiving state.[email] |
|||||||
Proposal:
The proposal is to change the 400 line in Table 17 to take into account both these cases: <proposal> 400 Bad Request If the media type does not correspond to a SOAP message, indicates a problem with the received HTTP request message. This operation SHOULD NOT be repeated with the same message content. The message exchange is regarded as having completed unsuccessfully. Instantiated Property Value context:FailureReason "fail:BadRequest" Next State: Fail If the media type corresponds to a SOAP message, indicates a problem with the received SOAP message. This operation SHOULD NOT be repeated with the same message content. The local binding instance continues to receive the incoming message. Instantiated Property Value context:FailureReason "fail:BadRequest" Next State: Sending+Receiving </proposal>See also email,email. |
|||||||
Resolution:
Rationale for changes: 400 and 500 could both be generated by a server with or without a SOAP fault in the body of the response: table 23 defines responses including SOAP faults for both of these status codes, a HTTP server could also generate either prior to SOAP processing. The current text assumes that 400 will not have a SOAP fault in the body and 500 will have a SOAP fault in the body Proposed changes: Paragraph before table 17. <current> Table 17 details the transitions that take place when a requesting SOAP node receives an HTTP status line and response header. Table 17 refers to some but not all of the existing HTTP/1.1 [RFC 2616] status codes. In addition to these status codes, HTTP provides an open-ended mechanism for supporting status codes defined by HTTP extensions (see [RFC 2817] for a registration mechanism for new status codes). HTTP status codes are divided into status code classes as described in [RFC 2616], section 6.1.1. The SOAP HTTP binding follows the rules of any HTTP application which means that an implementation of the SOAP HTTP binding must understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response must not be cached. </current> <proposed> Table 17 details the transitions that take place when a requesting SOAP node receives an HTTP status line and response header. <new>For some status codes there are two possible next states: Fail and Sending+Receiving. <FriendlyAmendment> In these cases the transition is dependent on whether a SOAP message is present in the HTTP response. If a SOAP message is present, the next state is "Sending+Receiving"; otherwise the next state is "Fail". <FriendlyAmendment> </new> Table 17 refers to some but not all of the existing HTTP/1.1 [RFC 2616] status codes. In addition to these status codes, HTTP provides an open-ended mechanism for supporting status codes defined by HTTP extensions (see [RFC 2817] for a registration mechanism for new status codes). HTTP status codes are divided into status code classes as described in [RFC 2616], section 6.1.1. The SOAP HTTP binding follows the rules of any HTTP application which means that an implementation of the SOAP HTTP binding must understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response must not be cached. </proposed> Table 17 row for 400, adding Sending+Receiving as a possible next state <current> Indicates a problem with the received HTTP request message. The problem can be malformed XML in the request message envelope. This operation SHOULD NOT be repeated with the same message content. The message exchange is regarded as having completed unsuccessfully. </current> <proposed> Indicates a problem with the received request message. </proposed> Table 17 row for 500, adding Fail as a possible next state <current> Indicates that the response message contained in the following HTTP response entity body may contain a SOAP fault. Other internal server errors may be the cause of this status code. The local binding instance continues to receive the incoming message. </current> <proposed> Indicates a server problem or a problem with the received request message. </proposed>[email] |
|||||||
384 | spec | n/a | meta | Design | Closed | Mark Baker | |
Title: Are gateways SOAP intermediaries? | |||||||
Description:
The current definition of a SOAP intermediary says; "A SOAP intermediary is both a SOAP receiver and a SOAP sender and is targetable from within a SOAP message. It processes the SOAP header blocks targeted at it and acts to forward a SOAP message towards an ultimate SOAP receiver." "SOAP message path" is defined as; "The set of SOAP nodes through which a single SOAP message passes. This includes the initial SOAP sender, zero or more SOAP intermediaries, and an ultimate SOAP receiver. "Ultimate SOAP receiver" includes this in its definition; "An ultimate SOAP receiver cannot also be a SOAP intermediary for the same SOAP message" The second definition suggests that the ultimate SOAP receiver cannot itself be a SOAP intermediary. The third point explicitly says this, though with the qualification "for the same SOAP message" (which is unclear). But the first, in the first sentence, would seem to include gateways in its definition, as they meet all three criteria; SOAP receiver, SOAP sender, targettable. At this late stage, I'm only going to ask that the specification be clear about how gateways fit, or don't, as the case may be. P.S. section 2.1 redefines "SOAP intermediary" in the second sentence of the first paragraph, differently than in section 1.4.3. I suggest it be removed from 2.1.[email] |
|||||||
Proposal: | |||||||
Resolution:
In response to issue 384, the WG has decided to say that SOAP gateways are not SOAP intermediaries and therefore not to introduce the notion of a SOAP gateway into the SOAP spec. The reason is that a SOAP intermediary is defined in terms of a SOAP receiver and a SOAP sender which the WG did not associate with traditional gateway functionality. The WG recognizes that there may be gateways at the level of underlying protocols but the SOAP spec does not provide an architecture for talking about such gateways (see also [1] (Member only)). The WG agrees with your editorial suggestion and will fix the spec accordingly.[email] |
|||||||
385 | AF doc | n/a | meta | Design | Closed | Kirill Gavrylyuk | |
Title: Add a conformance clause | |||||||
Description:
1. Conformance clause should be added that would - describe the subject of conformance (a binding specification) - summarizes what does it mean to conform to this specification - List dependencies: describe what other parts of SOAP 1.2 specification/other specifications a binding must conform to in order to conform to this specification[email] |
|||||||
Proposal: See email | |||||||
Resolution:
The XMLP WG has agreed to resolve issue 385 by adding a new Conformance section to the Attachment Feature document containing the following text: "This document describes an attachment feature which is an abstract model, and conformance is a property of binding specifications or modules that use this model. A binding specification or a module using this model is conformant if it follows all the requirements of this specification (see in particular 6. Implementation)."[email] |
|||||||
386 | AF doc | n/a | meta | Design | Closed | Kirill Gavrylyuk | |
Title: Prefix att is not defined | |||||||
Description:
2. Prefix att is not defined. QNames of the form att:* are used, but prefix att is not associated with any namespace. Would be good to explicitly associate it in the prose with the URI http://www.w3.org/2002/06/soap/features/attachment[email] |
|||||||
Proposal: See proposal. | |||||||
Resolution:
As the consequence of the resolution of another issue, the "att" Prefix is no more used as a Namespace prefix in this document (this is not yet reflected in the spec). Accordingly, the Working Group has decided to solve issue 386 by taking no action.i[email] |
|||||||
387 | AF doc | n/a | meta | Design | Closed | Kirill Gavrylyuk | |
Title: Change "can" to "may" (...) to conform to RFC 2119 | |||||||
Description:
3. Sec 2 - Change "can" to "may" in the "Protocol binding specifications can use this URI" to conform to RFC 2119. Unless there is a good reason, we suggest to even change it to "should", so that there is not ambiguity on whether the specific binding uses the soap1.2 attachment feature.[email] |
|||||||
Proposal: See proposal. | |||||||
Resolution:
The working group has agreed to close this issue by changing section 2 to be: <section2> 2. SOAP Feature Name This Attachment Feature is identified by the URI (see [SOAP Part 1] SOAP Protocol Binding Framework): * "http://www.w3.org/2002/06/soap/features/attachment". </section2>[email] |
|||||||
388 | AF doc | n/a | meta | Design | Closed | Kirill Gavrylyuk | |
Title: explicitly reference the equivalence rules used for the URIs | |||||||
Description:
4. Section 6: We suggest to explicitly reference the equivalence rules used for the URIs when the message parts are identified. (We believe editors meant the URI equivalence rules specified in the URI spec [3]). The fact that XML namespace spec uses different equivalence rules for namespace URIs then the original URI spec causes a confusion among developers on which rules to use in each case of the URIs use.[email] |
|||||||
Proposal: See proposal | |||||||
Resolution:
You raised the following last call issue against the XML Protocol Attachment Feature document: "4. Section 6: We suggest to explicitly reference the equivalence rules used for the URIs when the message parts are identified. (We believe editors meant the URI equivalence rules specified in the URI spec [3]). The fact that XML namespace spec uses different equivalence rules for namespace URIs then the original URI spec causes a confusion among developers on which rules to use in each case of the URIs use." Section 6 of SOAP 1.2 Part 1 discusses uses of URIs in SOAP including determination of a base URI for relative URIs and URI equivalence rules. We propose to resolve your issue by adding a reference to this section to the AF document (without duplicating text between Part 1 and the AF specification). The revised text reads: * A mechanism by which each part is identified using one (or more) URI(s), see (ref to SOAP Part 1, 6. Use of URIs in SOAP). The URI scheme used MAY but need not be the same for all parts. The URI scheme used for multiple identifiers of a single part MAY but need not be the same. Note: the ability to identify a single part with multiple URIs is provided because, in general, the Web architecture allows such multiple names for a single resource. It is anticipated that most bindings will name each part with a single URI, and through the use of base URIs, provide for absolute and/or relative URI references to that URI.[email] |
|||||||
389 | spec | n/a | Editorial | Design | Closed | Jacek Kopecky | |
Title: Possibly editorial problem in Data Model and Encoding | |||||||
Description:
The section 2 [1] - SOAP Data Model - speaks (among others) about simple and compound values, terminal and non-terminal graph nodes, structs and arrays. It says that a simple value is a terminal graph node and that a compound value is a non-terminal graph node. The latter need not be true, consider an empty struct or array - both are terminal nodes but certainly not simple values. Further, the distinction between terminal and non-terminal graph nodes brings confusion when combined with the newly agreed-on attribute name 'nodeType' (created for issue 231 [2] resolution) because while section 2.2 differentiates terminal and non-terminal nodes and single- and multi-reference nodes while this nodeType attribute introduces a third differentiation. Since the terminal vs. non-terminal node distinction is only used in places where it is used (mostly?) improperly and where what matters is the difference between a simple value and a compound value, represented by a struct node or an array node (these names are introduced in section 2.3), I think the terminal and non-terminal distinction should be removed or replaced by the compound vs. simple value distinction. My opinion is that this would be an editorial change because it only simplifies terminology used in a few places in section 2 and 3 of the Adjuncts.[email] |
|||||||
Proposal: See proposal. | |||||||
Resolution:
The Working Group has decided to close the editorial issue 389 using the proposed text [2] (amended in [3]). The issue deals with the distinction of terminal and non-terminal nodes in the Data Model and Encoding in the Last Call draft of SOAP 1.2, which was only used in places where it was unnecessary and/or incorrect. The resolution basically removes the distinction.[email |
|||||||
390 | AF doc | n/a | meta | Design | Closed | Hugo Haas | |
Title: usage of URIs for identifying secondary parts | |||||||
Description:
The motivation for the usage of URIs for identifying secondary parts is incomplete. It seems apparent for performance and other reasons that a part will be a representation of a resource. And packaging will enable higher performance. We recommend the XML Protocol Working Group to document the motivations for using the SOAP Attachment Feature, for example with a set of usage scenarios. In some cases, it seems likely a move from use of a resource on the web to adding a part to the package could result in a need to modify the representation of any reference to that resource. For example, a reference in a SOAP element might be <http://example.com/Sound.wav>. My SOAP application now uses some SOAP attachment feature, perhaps MIME. The representation is now identified by <cid:someidentifierforSoundwav>. I have to change the SOAP message to use the new URI. It would seem cleaner if the reference stayed the same, and the SOAP application did not have to modify these references. To avoid this problem, we recommend specifically calling out the DIME features allowing an included part to be identified using its existing URI. For MIME, the text should discuss the inclusion of a content-location header to server the same purpose. This would allow a recommendation along the lines of "applications SHOULD avoid a need to convert references as parts are added to a SOAP message."[email] |
|||||||
Proposal: See email | |||||||
Resolution:
The first part of the issue is a general request to explain why and when using the attachments (rather than links to resources): " We recommend the XML Protocol Working Group to document the motivations for using the SOAP Attachment Feature, for example with a set of usage scenarios." In AF's doc introduction [1], the 3 bullets give use cases of attachments from a SOAP point of view. An attachment is a particular part of the SOAP message. We don't see any further need to give use cases of attachment along with some particular implementations and particular bindings. The attachment feature was designed initially to complete the SOAP specification. The second part of the issue asks clarifications about how resources on the web (referenced by a URI) are added as a part (how a change of reference is handled): " For example, a reference in a SOAP element might be <http://example.com/Sound.wav>. My SOAP application now uses some SOAP attachment feature, perhaps MIME. The representation is now identified by <cid:someidentifierforSoundwav>. " We claim that the semantics is not the same when you refer to an external URI than when you attach a particular representation of that resource (a snapshot). We allow both external and internal reference to a resource, which are different usages, but we do not preclude any. Wrt referencing attachment in general, it is a binding problem and not an attachment feature issue. It is possible to refer either to external URIs, either to parts of the secondary bag. The way the URI is resolved is certainly not in scope of the Attachment feature.[email] |
|||||||
391 | AF doc | n/a | meta | Design | Closed | Hugo Haas | |
Title: how IDREF/URIs would be dereferenced | |||||||
Description:
The SOAP encoding allows references by IDREFs inside the SOAP envelope. A natural and common way to reference something on the Web is to use a reference to a resource using an http: URI. The Attachment Feature document suggests that such references are to be handled by the Attachment Feature (example 3 in section 6). It is unclear, with the current SOAP Version 1.2 specification, how such URIs would be dereferenced, i.e. as part of the HTTP binding, by the SOAP processor, etc. Some clarity about this example is desired. Also, in such a case where the secondary parts do not travel along with this message, the term "attachment" is awkward to talk about those resources that need to be dereferenced.[email] |
|||||||
Proposal: See email | |||||||
Resolution:
At the SOAP WG F2F meeting on October 30th, the WG agreed to resolve this issue by adopting the proposal in [3].[email] |
|||||||
392 | AF doc | n/a | meta | Design | Closed | Hugo Haas | |
Title: Intermediaries and secondary parts | |||||||
Description:
We are concerned about the interaction of URI addressing schemes to secondary parts and the SOAP execution model which permits various SOAP headers to be inserted and deleted by intermediaries under appropriate conditions (roles must match, software modules must exist, etc.). Are there similarly conditions under which intermediaries may insert and delete secondary parts? For example, are they allowed to create "dangling URIs"? Secondly, is it clear which URI schemes are impervious to insertion, deletion, and modification of secondary parts? For example, might there be a uniqueness problem with IDREFs?[email] |
|||||||
Proposal: See proposal | |||||||
Resolution:
You raised earlier issue 392. The issue contains two parts: [P1] You asked whether intermediaries are allowed to add/remove secondary parts. More generally, you wondered whether there should be an equivalent to our well-known processing model, but one that would apply to secondary parts, not header blocks. [P2] You wondered whether some URI schemes are better adapted to insertion, deletion, and modification of secondary parts. The XMLP WG considers that this issue should be addressed by the AF specification and has decided to incorporate the text below. Regarding part 2, the WG considers that particular URI schemes should not be prescribed or rejected by the abstract AF specification, but by concrete attachment specifications only. [New section in AF document] Intermediary Considerations =========================== A SOAP message can travel through zero or more SOAP intermediaries. This sections describes the requirements posed on SOAP intermediaries supporting this specification. A SOAP intermediary MUST be able to access any secondary part. A forwarding SOAP intermediary MUST in general forward every secondary parts contained in the incoming SOAP message, except when the specification for a processed SOAP header block calls for the part to be removed or changed. An active SOAP intermediary MAY change or remove any secondary part even in the absence of such a mandate. A SOAP intermediary MAY insert new secondary parts. The integrity of references (i.e. URIs) to secondary parts MUST be maintained accross SOAP intermediaries. That is, a URI which resolves to a secondary part in an inbound SOAP message MUST continue to resolve to that part in the outbound message, unless that part was removed by the SOAP intermediary.[email] |
|||||||
393 | AF doc | n/a | meta | Design | Closed | Hugo Haas | |
Title: Concrete attachment specification | |||||||
Description:
The Web Services Architecture Working Group encourages the XML Protocol Working Group to produce a concrete packaging (attachment) specification to validate the SOAP/1.2 Attachment Feature specification. A normative standard for a concrete specification is also important for reference from other standards and specifications and is considered a high priority by the WSAWG. The XML Protocol Working Group may be the most appropriate venue for this work; if not, the Web Services Architecture Working Group will probably recommend that a new Working Group be chartered to do this in the near future because the lack of a concrete specification that can be the basis for interoperable SOAP attachments implementations is a hole in the Web services architecture that needs to be addressed as soon as possible.[email] |
|||||||
Proposal: See proposal | |||||||
Resolution:
The XML Protocol WG has agreed in principle to investigate the creation of a normative specification of a concrete instantiation of the SOAP/1.2 Attachment Feature. It will proceed by conducting due diligence with respect to IPR issues, gathering requirements, etc. It is anticipated that existing specifications will provide a reasonable starting point. The timing of this activity will take into account the higher priority of getting the primary SOAP 1.2 specifications to recommendation.[email] |
|||||||
394 | spec | n/a | meta | Design | Closed | Noah Mendelsohn | |
Title: Some unprocessed headers should stay | |||||||
Description:
The Problem ----------- Among the reasons that we have the "next" role is for headers that carry information to be available to all downstream nodes. One of the simplest scenarios would be to have such a header that would travel with the message, to be available to those nodes that "understand" the header, and to be ignored and passed on by nodes that do not understand it. As a simple example, I might want to put in the header indicating the time at which the message was originally sent. More substantively, I might wish to put in a digital signature, to be checked by those who care, and ignored but retained by others. SOAP 1.2 as proposed cannot support these simple scenarios. Why? Because section 2.7.1[1] makes clear that a forwarding intermediary MUST remove from the message all headers targeted to it, and can trigger reinsertion only by processing and understanding a header. In the case where you don't understand the header, you must remove it. It's essential to note that we are considering the case of mustUnderstand='false'; there is no problem with the 'true' case. Approaches to Resolving the Problem ----------------------------------- Discussion of this problem has been going on at a low level for awhile, in part because some of us have been trying to decide whether the existing specification can somehow be made to do the right thing. Given that we are in last call, that would obviously be a desirable approach. So, here I briefly outline some of the approaches that were considered, and then in the next section I propose one that seems to some of us to be the best. It is tempting to ask whether a user might be able to design specific headers and/or roles that would meet the need. In other words: if I define a role and some headers to use with it, then I could say that you wouldn't assume that role unless you knew the specification for at least one of the headers, and that specification would implement a feature to change the relay rules for that role. My personal conclusion is that this is possible in principle, but would not be practical when one considers the way that most SOAP software will in fact be built. Reason: the core rules regarding the relaying of headers are baked into section 2.7.1, and in practice will often be implemented by general-purpose SOAP middleware. The key point is that such middleware will in general be written to treat all user-defined roles identically. Allowing particular roles to change the relay rules requires that such middleware have pluggable handlers that key on specific role names, and this is something that few of us anticipate doing. There is another alternative which is also coherent, and indeed is more powerful than the one proposed below, but which seems to be overkill and would probably take us back to last call. That alternative would be to introduce a new attribute for use on header entries along the lines of relayIfNotProcessed='true'. Thus: <soap:Header> <nrm:myHeader role="..any role you like..." mustUnderstand="false" relayIfNotProcessed="true"> ... </nrm:myHeader> </soap:Header> This seems to work, and has the capability of working with any role. It just seems like more power and complexity than we need to deal with the specific use case. If we were to get serious about this proposal, there would be several details requiring refinement, but for now I am just suggesting that this is not the direction to go. Another possibility that has been raised would be to change the default behavior to be: "leave in place any header entries that are not processed". Optionally, we could additionally define a relayIfProcessed override if the group felt it to be worth the trouble. My impression is that some who have considered changing the default rules like the idea, but some feel that it doesn't meet a need to have headers that do indeed disappear when unprocessed. For the record, I quite like the idea, but (a) am not ready to take the lead in pushing it in the face of any significant opposition and (b) would not want to go back to last call if this were deemed a serious change-- I'm not sure it is.[email] |
|||||||
Proposal:
Anyway, having done the above analysis, several of us conclude that: * The use case is important that we must find a way to meet it * The draft as written doesn't give explanation of how * We need a simple, minimally invasive fix to what we have We propose one new builtin role to be called: http://www.w3.org/2002/06/soap-envelope/role/relay . In most respects, this role would be like any other. Any intermediary or ultimate receiver MAY choose to assume this role. The one significant difference, and it is one that we believe has to be baked into the specification from day one (I.e. would be an incompatible change if made later) is that section 2.7.1 will be changed as follows: <original> Forwarding SOAP intermediaries MUST process the message according to the SOAP processing model defined in 2.6 Processing SOAP Messages. They MUST also remove from the SOAP message all SOAP header blocks targeted at themselves, prior to forwarding, regardless of whether these header blocks were processed or ignored. In addition, forwarding SOAP intermediaries MUST also obey the specification for the SOAP forwarding feature being used. The specification for such a feature MUST describe the required semantics, including the rules describing how the forwarded message is constructed. Such rules MAY describe placement of inserted or reinserted SOAP header blocks. Inserted SOAP header blocks might be indistinguishable from one or more of the header blocks removed above. </original> <proposed> Forwarding SOAP intermediaries MUST process the message according to the SOAP processing model defined in 2.6 Processing SOAP Messages. In addition, when generating a SOAP message for the purpose of forwarding, they MUST: * For any processed SOAP header block, as well as for ignored SOAP header blocks targeted to the node using a role other than http://www.w3.org/2002/06/soap-envelope/role/relay: remove the header block prior to forwarding * Retain all SOAP header blocks that were targeted at the forwarding node using the role "http://www.w3.org/2002/06/soap-envelope/role/relay" but ignored during processing. In addition, forwarding SOAP intermediaries MUST also obey the specification for the SOAP forwarding feature being used. The specification for such a feature MUST describe the required semantics, including the rules describing how the forwarded message is constructed. Such rules MAY describe placement of inserted or reinserted SOAP header blocks. Inserted SOAP header blocks might be indistinguishable from one or more of the header blocks removed above. </proposed>[email] + See following thread. [New proposal] |
|||||||
Resolution:
The XMLP WG recognises this is an important issue. It has decided to introduce a new "relay" attribute. This attribute lets nodes explitely specify which header block should be forwarded. More precisely, it indicates which unprocessed header blocks, targetted at a node assumed by an intermediary, must be forwarded. In your email, you outlined a similar solution ("relayIfNotProcessed"), although you recommended adopting a simpler proposal ("relay" role) at this late stage of the recommandation process. After carefull consideration and intense discussion, the WG decided to go for the more elaborate solution, for the following reasons: 1) The concepts of targetting and forwarding are separate and should remain so. 2) With your proposed solution, it would be impossible to target a header block at a user-defined role. A relayable block would have to always be targetted at the "relay" role, which defeats the whole purpose of the "role" attribute. 3) Both solutions would result in about the same amount of changes to the spec anyway. Since your initial email, you have indicated during at least two different teleconferences that you would indeed prefer the more general solution; we thus trust that you will agree with the WG's resolution. Please let us know asap if you think otherwise. The WG has also taken this opportunity to introduce a new table which clarifies and summarizes when and how nodes are allowed to forward messages.[email] |
|||||||
395 | spec | n/a | meta | Design | Closed | Noah Mendelsohn | |
Title: Check in HTTP binding that we are prohibiting DTDs. | |||||||
Description:
Log potential issue: Check in HTTP binding that we prohibit DTDs.See F2F minutes, irc log |
|||||||
Proposal: | |||||||
Resolution:
In response to XML Protocol Last Call issue 395, the WG has decided to adopt the resolution stated in [2][email] |
|||||||
418 | AF doc | n/a | meta | Design | Closed | Martin Gudgin | |
Title: Comments on SOAP 1.2 Attachment Feature | |||||||
Description:
1. The att:SOAPMessage property should be described as being an XML Infoset ( this is the abstract structure of a SOAP message ) 2. The att:SecondaryPartBag should be a sub-property of the att:SOAPMessage, that is it, and the representations it contains, should be contained entirely within the XML Infoset of the SOAP message. In general, the notion of information being outside the SOAP envelope seems to be problematic, given that the processing model[2] of SOAP is defined in terms of an XML Infoset.[email] |
|||||||
Proposal: | |||||||
Resolution:
The WG has decided to deprecate the attachment feature document and will be taking no action with respect to this issue.[email] |
|||||||
468 | mtom | n/a | editorial | Design | Closed | Hugo Haas | |
Title: SOAP-specificity of the HTTP Transmission Optimization Feature name | |||||||
Description:
While working on MTOM and XOP description, we realized that the name "HTTP Transmission Optimization Feature" was confusing. It is a SOAP feature, i.e. it cannot be used without sending SOAP messages. Yet, its name is very general and doesn't reflect that. It is particularly confusing when considering that one could define a feature which would provide XOP optimization for arbitrary XML over HTTP, which one would probably want to call Generic HTTP Transmission Optimization Feature, or maybe even HTTP Transmission Optimization Feature too. We would appreciate to have this SOAP-specificity reflected in its name. As a matter of comparison, the SOAP Web Method Feature defined in the Part 2 Recommendation, which arguably has a scope of application which is broader than just SOAP, had a name which was pointing out SOAP-specificity.[email] |
|||||||
Proposal: | |||||||
Resolution:
You raised an issue 468[1] on the MTOM specification[2]. The editors have changed 'Abstract Transmission Optimization Feature' to 'Abstract SOAP Transmission Optimization Feature' and 'HTTP Transmission Optimization Feature' to 'HTTP SOAP Transmission Optimization Feature'.[email] |
|||||||
469 | XOP | n/a | editorial | Design | Closed | Mark Nottingham | |
Title: Examples in XOP LC Draft | |||||||
Description:
The examples in the XOP Last Call Draft use the 'text/xml' media type for the XOP Document, and in the type parameter of the package's media type. Instead, a XOP-specific media type should be used. Also, I don't find a direct RFC2119 requirement to use a XOP-specific media type in a XOP Package, which I don't think reflects the wishes of the Working Group. An appropriate place might be item 5 in section 3.1.[email] |
|||||||
Proposal: | |||||||
Resolution:
The editors have corrected the spec, chaning 'text/xml' to 'application/soap+xml' in examples and adding 'XOP-specific' to Section 3.1 Bullet 5.[email] |
|||||||
470 | XOP | n/a | meta | Design | Closed | Graham Klyne | |
Title: text/xml for root multipart/related element | |||||||
Description:
Section 1.2: text/xml for root multipart/related element The choice of a text/... MIME type for this purpose seems rather, er, perverse to me. The intent of text/... MIME types is for data content that can reasonably be read as such by a human user [1]. text/html is regarded by at least one of MIME's designers as a mistake [2]. I really don't think that an XML SOAP envelope falls into the category of human-readable text. I suggest: (a) use application/xml, or (b) register a new application/...+xml MIME type for this purpose. I see in section 5 you describe application/soap_xop+xml, so I guess that's just a typo in the examples? Section 5: Looking at: [[ For example, if the format identified by "application/soap+xml" is to be packaged as XOP serializations, then a XOP-specific media type (e.g., "application/soap_xop+xml") MUST be registered. A XOP Package using the Multipart/Related packaging mechanism and serializing such an Infoset would have a package media type of "multipart/related" and a root media type of "application/soap_xop+xml". ]] This seems a bit awkward to me. Has any consideration been given to defining a single MIME content-type, say application/xop+xml, having a parameter to specify the original MIME type; hence: Content-type: application/xop+xml;original-content-type="application/soap+xml" Among other things, I think this would make it easier to implement a completely generic XOP serializer/deserializer since no special knowledge of any specific MIME type (other than application/xop+xml) would be required.[email] |
|||||||
Proposal: | |||||||
Resolution:
The Working Group today resolved to take a modified approach, outlined below, whereby the type parameter contains a content-type instead of a media type (i.e., it can contain parameters). This allows such parameters to "show through" both the root part's type parameter as well as the package's start-info parameter. It does mean that some escaping may be necessary, but that was thought an acceptable cost in exchange for the simplicity of the approach. * Section 1.2 Example In Example 2, change: [[[Content-Type: Multipart/Related;boundary=MIME_boundary; type=application/soap_xop+xml;start="<mymessage.xml@example.org>"]]] to: [[[Content-Type: multipart/related;boundry=MIME_boundary; type="application/xop+xml";start="mymessage.xml@example.org>"; startinfo="application/soap+xml;action=\"http://www.example.com/ myAction\""]]] Change: [[[Content-Type: application/soap_xop+xml; charset=UTF-8]]] to: [[[Content-type: application/xop+xml; charset=UTF-8; type="application/soap+xml;action=\"http://www.example.com/ myAction\""]]] * Section 3.1 Creating XOP Packages In bullet 5, change "appropriate XOP-specific media type" to "application/xop+xml media type" * Section 4.1 MIME Multipart/Related XOP Packages Replace the second paragraph with: """The root MIME part is the root of the XOP Package, and MUST be a serialisation of the XOP Infoset using any W3C Recommendation-level version of XML (e.g., [XML 1.0], [XML 1.1]), and MUST be identified with a media type of "application/xop+xml" (as defined below). The "start-info" parameter of the package's media type MUST contain the content type associated with the content's XML serialisation (i.e., it will contain the same value as that of the root part's "type" parameter).""" * Section 5 Identifying XOP Packages Replace the section with: """ XOP Documents, when used in MIME-like systems, are identified with the "application/xop+xml" media type, with the required "type" parameter conveying the original XML serialisation's associated content type. Note that when the type parameter contains reserved characters, it needs to be appropriately quoted and escaped. For example, a XOP Package using MIME Multipart/Related packaging to serialise a SOAP 1.2 message [SOAP1.2] with an action parameter of "http://www.example.com/foo" would label the package itself with the "multipart/related" media type; the root part's media type is "application/xop+xml", with a "type" parameter containing "application/soap+xml;action=\"http://www.example.net/foo\"". 5.1 Registration MIME media type name: application MIME subtype name: xop+xml Required parameters: * "type" This parameter conveys the content type associated with the XML serialisation of the XOP Infoset, including parameters as appropriate. Optional parameters: * "charset" This parameter has identical semantics to the charset parameter of the application/xml media type as specified in RFC 3023 [RFC 3023]. Encoding Considerations: Identical to those of application/xml as described in RFC 3023 [RFC 3023], section 3.2. Security Consideration: In addition to application-specific considerations, XOP has the same security considerations described in RFC 3023 [RFC 3023], section 10. Interoperability Considerations: There are no known interoperability issues. Published Specification: This document. Applications which use this media type: No known applications currently use this media type. Additional Information: File extension: XOP Fragment Identifiers: Identical to that of application/xml as described in RFC3023 [RFC3023] Base URI: As specified in RFC 3023 [RFC 3023], section 6. Macintosh File Type code: TEXT Person and email address to contact for further information: Mark Nottingham <mnot@pobox.com> Intended usage: COMMON Author/Change controller: The XOP specification is a work product of the World Wide Web Consortium's XML Protocol Working Group. The W3C has change control over this specification. """[email] |
|||||||
471 | XOP | n/a | editorial | Design | Closed | Graham Klyne | |
Title: Typo in RFC 2557 Authors' name. | |||||||
Description:
B.1 References: The reference to RFC 2557 mis-spells one of the authors' name (J Palme).[email] |
|||||||
Proposal: | |||||||
Resolution:
You raised an issue 471[1] on the XOP specification[2]. This error has been corrected in the latest editor's copy.[email] |
|||||||
472 | XOP | n/a | meta | Design | Closed | Jacek Kopecky | |
Title: term definition | |||||||
Description:
1) Section 1.1 defines the term Optimized Content and does not define the term Extracted Content; the rest of the spec uses the latter term in multiple places, I think these terms should be consolidated or the latter defined as different from the former.[email] |
|||||||
Proposal: | |||||||
Resolution:
You raised an issue 472[1] on the XOP specification[2]. The WG has agreed to use the term Optimized Content rather than a mixture of Extracted Content and Optimized Content.[email] |
|||||||
473 | XOP | n/a | meta | Design | Closed | Jacek Kopecky | |
Title: white space and base64 | |||||||
Description:
2) the example in section 1.2 contain white space around the base64 characters, and same below around the xop:Include element, should that be removed? Or should it be pointed out somewhere that such space is in fact insignificant per some spec? Section 3.1 specifies bullet 3 says no space allowed preceding, inline or following the content...[email] |
|||||||
Proposal: | |||||||
Resolution:
The WG will clarify that elements to be optimized must only contain character information items. The WG will also amend the example to fix the whitespace problems by removing whitespace around the <xop:Include> element and the base64 characters.[email] |
|||||||
474 | XOP | n/a | meta | Design | Closed | Jacek Kopecky | |
Title: XOP Infoset / Package | |||||||
Description:
3) Section 3.1, last sentence, should XOP Infoset be changed to XOP Package here? Content is not encoded into the XOP Infoset after all, it's extracted from it. 8-)[email] |
|||||||
Proposal: | |||||||
Resolution:
You raised an issue regarding XOP. The WG agree with your suggestion that XML Infoset should read XML Package in the last sentence of Section 3.1 and will make this change.[email] |
|||||||
475 | XOP | n/a | meta | Design | Closed | Jacek Kopecky | |
Title: packaging and root part | |||||||
Description:
4) Section 4 says any packaging mechanism can be used, but the spec refers to the "root part" in multiple places - should it be said that any packaging mechanism has the notion of a root part?[email] |
|||||||
Proposal: | |||||||
Resolution:
You raised an issue[1] regarding XOP[2]. The WG agrees with your concern regarding XOP consistency when describing XOP packaging requirements and the notion of a root part. The working group will change the text in Section 4, paragraph 1 to read: "Such packaging mechanisms MUST be able to represent, with full fidelity all the parts created according to 3 XOP's Processing Model (see 3.1 Creating XOP Packages), and MUST be used in a manner that provides a means of designating a distinguished root part." [---] From Jacek Kopecky I'd suggest a small friendly amendment here: Such packaging mechanisms MUST be able to represent, with full fidelity all the parts created according to 3 XOP's Processing Model (see 3.1 Creating XOP Packages), and MUST be used in a manner that provides a means of designating a distinguished root (main, primary etc.) part. Just added the parenthesized part of the last line to explain better that it need not be called "root" part, but XOP calls it that. 8-) [---] From Michael Mahan (on behalf of XMLP WG) The WG has agreed to accept your friendly amendment.[email, email, email] |
|||||||
476 | XOP | n/a | meta | Editorial | Closed | Jacek Kopecky | |
Title: Editorial LC comments on XOP | |||||||
Description:
1) just before 1.1, decapitalize the section numbers in the overview - instead of Section Four say Section four. 2) in 1.1, drop second reference to XML InfoSet 3) xop:Includeelement add space, in multiple places in the spec, same with hrefattribute in multiple places and other similar spacing problems - suggest searching for the pair >< in the XML or for a letter and < with no space in between, I guess. 4) Section 1.2, [media type] link should be filled in 5) Section 1.3 add spacing and/or padding to table to make it more readable 6) Section 2 heading: XOP Infosets Constructs - drop first plural - XOP Infoset Constructs 7) Sections 2.1, 2.2, xop:Include element MUST have the name of Include? Oh, please! 8-) I suggest taking the approach from Representation header spec. 8) Section 2.1 third bullet: ... It MUST NOT change the semantics... "it" is ambiguous, I suggest using "the element" 9) Section 2.1 fourth bullet: hrefattribute information items - space missing, drop 's' at the end (plural items) 10) consolidate spacing in references rfcxxxx and rfc xxxx (with/out space) 11) also, I believe some references are not properly pointing to their destinations (rfc reference in 2.2, third bullet), may be related to the problem above 12) Section 2.2 fourth bullet: its owner must be a xop:include element. period. 13) Section 3 heading: XOP's processing model - drop possessive -> "XOP processing model" 14) Section 3.2 ... has as its [children] a xop:Include... - mismatch of plural [children] and singular element, suggest a bit more verbose version that says that is the only child. 15) Section 3.2: ... replace its [children] with a char info items ... - drop indefinite article 'a' 16) Section 4.1 says the media type of the root part must be specific to XOP encoding of the actual data, 5 mentions application/soap_xop+xml, the example in 1.2 uses text/xml though, should use application/soap_xop+xml 17) Section 6.1 contains unbalanced parenthesis[email] |
|||||||
Proposal: | |||||||
Resolution:
You raised an issue 476 on the XOP specification. The editors have made the following changes(reflected in latest editors copy) > 1) just before 1.1, decapitalize the section numbers in the overview - > instead of Section Four say Section four. Changed to use Section 4 rather than Section Four ( see[3] ) > 2) in 1.1, drop second reference to XML InfoSet Done. > 3) xop:Includeelement add space, in multiple places in the spec, same > with hrefattribute in multiple places and other similar spacing problems > - suggest searching for the pair >< in the XML or for a letter and <> with no space in between, I guess. Done. > 4) Section 1.2, [media type] link should be filled in Done. > 5) Section 1.3 add spacing and/or padding to table to make it more > readable Done. Made the table 3 columns wide. > 6) Section 2 heading: XOP Infosets Constructs - drop first plural - XOP > Infoset Constructs Done > 7) Sections 2.1, 2.2, xop:Include element MUST have the name of Include? > Oh, please! 8-) I suggest taking the approach from Representation header > spec. Done. > 8) Section 2.1 third bullet: ... It MUST NOT change the semantics... > "it" is ambiguous, I suggest using "the element" Fixed. > 9) Section 2.1 fourth bullet: hrefattribute information items - space > missing, drop 's' at the end (plural items) Fixed. > 10) consolidate spacing in references rfcxxxx and rfc xxxx (with/out > space) Done. ( They now always have a space ) > 11) also, I believe some references are not properly pointing to their > destinations (rfc reference in 2.2, third bullet), may be related to the > problem above Fixed. > 12) Section 2.2 fourth bullet: its owner must be a xop:include element. > period. Done. > 13) Section 3 heading: XOP's processing model - drop possessive -> > "XOP processing model" Fixed. > 14) Section 3.2 ... has as its [children] a xop:Include... - mismatch of > plural [children] and singular element, suggest a bit more verbose > version that says that is the only child. Language amended. > 15) Section 3.2: ... replace its [children] with a char info items ... - > drop indefinite article 'a' Langage amended. > 16) Section 4.1 says the media type of the root part must be specific to > XOP encoding of the actual data, 5 mentions application/soap_xop+xml, > the example in 1.2 uses text/xml though, should use > application/soap_xop+xml Fixed. > 17) Section 6.1 contains unbalanced parenthesis Fixed.[email] |
|||||||
477 | MTOM | n/a | meta | Design | Closed | Jacek Kopecky | |
Title: Canonical / non-canonical | |||||||
Description:
Section 2.3.2 says receivers must not convert non-canonical representations to canonical, but do they actually have the opportunity? I think this text should be dropped as I don't think it's a good example for the rule before it.[email] |
|||||||
Proposal: | |||||||
Resolution:
The WG agree with your suggestion that the last sentence of paragraph 2 of Section 2.3.2 should be removed and will make this change.[email] |
|||||||
478 | MTOM | n/a | meta | Editorial | Closed | Jacek Kopecky | |
Title: Editorial LC comments on MTOM | |||||||
Description:
1) just before section 2.3.2 add text ...MUST not be optimized >>by implementations of this feature<< 2) 2.3.2 should say "should generate a fault" instead of "should fault" 3) 4.3.1.1 content-tranfer-encoding - missing 's' in transfer 4) 4.3.2 2nd paragraph says "The remaining of this section describes the perturbations", first it should be the "remainder", second there seem to be such formal perturbations, like the ones described in the table in 4.3.1.1[email] |
|||||||
Proposal: | |||||||
Resolution:
You raised an issue 478[1] on the MTOM specification[2]. The editors have made the following changes(reflected in latest editors copy[3]) > 1) just before section 2.3.2 add text ...MUST not be optimized >>by > implementations of this feature<< Done. > 2) 2.3.2 should say "should generate a fault" instead of "should fault" Done. > 3) 4.3.1.1 content-tranfer-encoding - missing 's' in transfer Done. > 4) 4.3.2 2nd paragraph says "The remaining of this section describes the > perturbations", first it should be the "remainder", second there seem to > be such formal perturbations, like the ones described in the table in > 4.3.1.1 The latter half of Section 4.3.2 has been amended to address this problem.[email] |
|||||||
479 | Representation | n/a | meta | Design | Closed | Jacek Kopecky | |
Title: LC comments on Resource Representation header | |||||||
Description:
1) section 1.2 needs to be filled 2) Section 2.1 talks about extracted content but makes no reference to XOP or MTOM, a reader new to these specs and starting with Representation header would have no idea what is being talked about. 3) Representation header is not a SOAP module, I think it would be beneficial for describing the messages (say in WSDL) if it had a formal name. 4) in section 2.2, should it be said that namespace-qualified elements and attributes on Rep elements must not be in Rep namespace? 5) section 2.3 should probably be marked informative 6) section 2.3.3, the example should probably be inside rep:Representation element[email] |
|||||||
Proposal: | |||||||
Resolution:
> 1) section 1.2 needs to be filled It has been filled, see the editors' copy > 2) Section 2.1 talks about extracted content but makes no reference to > XOP or MTOM, a reader new to these specs and starting with > Representation header would have no idea what is being talked about. Fixed, "extracted content" has been replaced by "resource" > 3) Representation header is not a SOAP module, I think it would be > beneficial for describing the messages (say in WSDL) if it had a formal > name. Fixed, the document now defines a SOAP Feature and a SOAP Module. The name of the specification has been changed to reflect that, it is now "Resource Representation SOAP Header Block" > 4) in section 2.2, should it be said that namespace-qualified elements > and attributes on Rep elements must not be in Rep namespace? The schema has been changed to reflect that, see [3] > 5) section 2.3 should probably be marked informative Done (by mean of stating that it is an example) > 6) section 2.3.3, the example should probably be inside > rep:Representation element Done.[email] |
|||||||
480 | Representation | n/a | meta | Design | Closed | Jacek Kopecky | |
Title: Editorial LC comments on Resource Representation header | |||||||
Description:
1) Section 2.1, Representation header is not required, but may be useful, when multiple references... 2) Section 2.1 should the space around base64 characters in the example be dropped? 3) Section 2.3.2: does reinsert have the [specified] prop w/value "true"? I believe not. 4) 2.3.2 Example Example - the link to the example should probably be titled otherwise 8-)[email] |
|||||||
Proposal: | |||||||
Resolution:
You raised an issue (#480) [1] regarding the Representation header [2] LC doc. The WG agreed to classify the issue as editorial and directed the editors to address your comment. Details: >1) Section 2.1, Representation header is not required, but may be >useful, when multiple references... The sentence in question in section 2.1 has been changed to read: "The Representation header block is also useful when multiple references to the same resource are required but duplication of the resource is undesirable." >2) Section 2.1 should the space around base64 characters in the example >be dropped? The space around the base64 characters has been removed. >3) Section 2.3.2: does reinsert have the [specified] prop w/value >"true"? I believe not. Section 2.2.3 (and not 2.3.2) is _not_ changed. The [specified] property value is indeed 'true'. This requires the attribute to be specified and not defaulted. >4) 2.3.2 Example Example - the link to the example should probably be >titled otherwise 8-) The sentence is question is now changed to: "An example of this usage is shown in Example 1."[email][email] |
|||||||
481 | XOP | n/a | meta | Design | Closed | Alex Danilo | |
Title: MIME boundaries not checked during XOP serialisation | |||||||
Description:
The creation of a XOP package as described in section 3.1 and illustrated in the example 1.2 converts original base64 encoded data into raw binary octets. It is entirely likely that a large enough sample of binary data will result in content that encodes the same sequence of octets that mark a MIME boundary for the output package. Such aliasing of MIME boundary octets will result in a broken XOP package that cannot be decoded back into the original XML infoset. Proposed solutions: 1) Scan and detect serialised binary data for the chosen MIME boundary separator and define an escaping mechanism to recode the binary data. 2) Scan and detect serialised binary data for the chosen MIME boundary separator and on detection choose a different MIME boundary string and rescan all binary attachments iteratively until no aliasing is detected. 3) Mandate use of the 'Content-Length:' header field in the binary part of the XOP package.[email] |
|||||||
Proposal: | |||||||
Resolution:
The XML Protocol has decided to close issue 481[1] with no action, because the issues you raise are well-understood and documented consequences of using MIME multipart packaging. Such discussion is more appropriate in a primer or other documentation.[email] |
|||||||
482 | XOP | n/a | meta | Design | Closed | Jun Fujisawa | |
Title: Reference to Base64 specification | |||||||
Description:
Section 1, the specification of base64 encoding in XOP is described in terms of base64Binary of XML Schema Part 2, and the definition of base64Binary data type refers to RFC 2045. Since more formal description of base64 has recently been provided as RFC 3548, I propose to use RFC 3548 as the primary reference specification of base64 encoding in XOP.[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP working group declined to adopt your suggestion as XOP requires a canonical form of base64 and RFC3548 does not define such a form. The XML Schema Part 2 specification does define such a form which is why we reference that specification rather than RFC3548.[email] |
|||||||
483 | XOP | n/a | meta | Design | Closed | Jun Fujisawa | |
Title: XOP: Why element content only? | |||||||
Description:
Section 1, it is stated that "As a result, only element content can be optimized". However, the reason why the attribute value cannot be optimized is not clear from the context.[email] |
|||||||
Proposal: | |||||||
Resolution:
You raised an issue, number 483[1] regarding langauge in section 1 of the XOP specification[2]. The working group agrees that it is not clear from the context why attribute content cannot be optimized. The reason, that an element is used to indicate where content has been optimized, is present in Paragraph 2 of Section 1, but the language you refer to is in Paragraph 5. The two intervening paragraphs make the context unclear. The Working Group will remove the text 'As a result,' from Section 5 so that it reads: "Only element content can be optimized; attributes, non-base64-compatible character data, and data not in the canonical representation of the base64Binary datatype cannot be successfully optimized by XOP."[email] |
|||||||
484 | XOP | n/a | meta | Editorial | Closed | Jun Fujisawa | |
Title: XOP: Identification of each example | |||||||
Description:
Section 1.2, assigning an identification number to each example (e.g. Example 1, Example 2...) will greatly help the reader of the printed specification to locate the right example from the description like "Example shows..".[email] |
|||||||
Proposal: | |||||||
Resolution:
You raised an issue, number 484[1], regarding numbering of examples in the XOP specification[1]. The editors have numbered the examples 1, 2 and 3 and used these numbers when refering to the examples.[email] |
|||||||
485 | XOP | n/a | meta | Editorial | Closed | Jun Fujisawa | |
Title: Avoid using SOAP in examples | |||||||
Description:
Examples in Section 1.2, I propose to use an XML vocabulary other than SOAP (such as SVG or XHTML) in order to show that XOP does not depend on SOAP (common misunderstanding).[email] |
|||||||
Proposal: | |||||||
Resolution:
You raised an issue[1] regarding examples in the XOP specification[2]. The latest editor's copy contains an example that uses text/xml. I trust this addresses your concern.[email] |
|||||||
486 | XOP | n/a | meta | Design | Closed | Jun Fujisawa | |
Title: XOP namespace declaration in Original Infoset | |||||||
Description:
In the first example, a namespace declaration for XOP is provided on the root soap:Envelop element. I don't think this is good because Original Infoset should not know anything about XOP (xop:Include element never occurs in Original Infoset). Also, "xmlmime:content-type" should be replaced by "xmlmime:contentType".[email] |
|||||||
Proposal: | |||||||
Resolution:
You raised an issue, number 486[1] regarding presence of the XOP namespace declaration on the root element in an example in the XOP specification[1]. The Working Group agrees that the example is unclear and will amend the example so that the namespace declaration appears on the Include element. The working group does note however, that it is possible for an original infoset to contain a namespace declaration for the XOP namespace, provided it does NOT contain any Include elements.[email][email] |
|||||||
487 | XOP | n/a | meta | Design | Closed | Jun Fujisawa | |
Title: Clarification on format change | |||||||
Description:
Section A.3, it is stated that "Change to the format MUST be identified by a new namaspace URI (i.e., they MUST define a new Include element information item in another namespace)." On the other hand, an extension to xop:Include element to add a namespace qualified child element or attribute is allowed according to Section 2.1. It is not clear such an extension is considered to be a "format change" mentioned in Section A.3 or not.[email] |
|||||||
Proposal: | |||||||
Resolution:
You raised an issue, number 487[1] regarding language in Section A.3 of the XOP specification[1]. The Working Group decided that use of the word 'format' in the second sentence was incorrect and that the word 'semantics' should be used instead as in the first sentence. The text will be amended to read: "XOP Documents allow extensions to the xop:Include element when they do not change its semantics. Changes to the semantics MUST be identified by a new namespace URI (i.e., they MUST define a new Include element information item in another namespace)."[email] |
|||||||
488 | Representation | n/a | meta | Design | Closed | Jacek Kopecky | |
Title: WS-Description WG's LC comment | |||||||
Description:
the WS-Description WG has reviewed the Last Call drafts of XOP, MTOM and Resource Representation Header specs and has two comments. 1) the Resource Representation header [1] is not a SOAP module and therefore does not have a formal name by which it can be referred (other than the element qname). We feel that making the header into a full module with its identification URI will help us describe applications that use it.[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP WG had decided to close issue 488 by adding a new section for the description of a SOAP module as proposed in [3].email |
|||||||
489 | MTOM | n/a | meta | Design | Closed | Jacek Kopecky | |
Title: WS-Description WG's LC comment | |||||||
Description:
the WS-Description WG has reviewed the Last Call drafts of XOP, MTOM and Resource Representation Header specs and has two comments. 2) we have discussed the ednote in section 4.3.1 in MTOM [2] on bindings that will reject some infosets and even though it doesn't affect our ability to describe SOAP services using MTOM, there was significant sentiment that an escaping mechanism for XOP elements be added in XOP or MTOM. It was noted that such escaping mechanism would only be used by nodes that cannot otherwise guarantee that xop:Include isn't present in their SOAP infosets; and such nodes, in order to be conformant, would have to scan the infosets for the presence of xop:Include elements before using MTOM. We don't think that performing the escaping would be a significant (show-stopping) addition to the overhead of the scan.[email] |
|||||||
Proposal: | |||||||
Resolution:
The WG has decided to take no further action with respect to this comment.[email] |
|||||||
490 | MTOM | n/a | meta | Design | Closed | Jonathan Marsh | |
Title: Describing which blobs are to be optimized | |||||||
Description:
Last week we approved this resolution of our Issue 207, which was to ask you to add a reference to the Media Type Description note and specifically mention that the expectedMediaType annotation could provide a source of information for determining which blobs are to be optimized. The specific text proposal below, and its position in the MTOM spec, are of course examples useful in reaching consensus on the issue within our group and you may find a better way to indicate this information in your spec. [..] > Ask the XMLP WG to augment the paragraph in MTOM > [http://www.w3.org/TR/soap12-mtom/#aof-sending] as indicated {{thus}}: > > "Note: the means of identifying element information items that contain > base64 encoded data in canonical lexical form are > implementation-dependent. Some implementations can identify such element > information items by construction (e.g., because a certain API may > create only canonical forms); others may check the characters prior to > sending{{, others may rely on information in the description such as the > presence and/or value of the xmlmime:expectedMediaType schema annotation > [reference to XMLMIME]}}. Because of the need to exactly preserve the > characters in the transmitted Infoset, non-canonical representations > MUST NOT be optimized."[email] |
|||||||
Proposal: | |||||||
Resolution:
The WG has added the text you requested, appending the additional phrase 'if a schema is available'.[email] |
|||||||
491 | MTOM | n/a | meta | Design | Closed | Martin Gudgin | |
Title: ContentID in MTOM | |||||||
Description:
I was under the impression that in resolving issue 451 that we were mandating the use of the cid: URI scheme ( and the corresponding ContentID MIME header ) when referencing MIME parts from xop:Include/@href. However, I can find no mention of this in XOP or MTOM. XOP in fact allows both Content-ID and Content-Location to be used ( see[4] ), but I thought at the MTOM level we were restricting to Content-ID only. I note that in private mail, several other members have the same recollection as me.[email] |
|||||||
Proposal: | |||||||
Resolution:
the XMLP WG agreed to resolve it by mandating the use of the "cid:" URI scheme in MTOM.[email] |
|||||||
492 | MTOM,XOP,Representation | n/a | meta | Editorial | Closed | Susan Lesch | |
Title: Bibliography | |||||||
Description:
A comment for your three Last Calls ending 29 June: SOAP Message Transmission Optimization Mechanism [1], SOAP Resource Representation Header [2] and XML-binary Optimized Packaging [3]. On the whole the drafts look nice but for some reason the References sections have no links. The W3C Bibliography Extractor writes references in W3C style very quickly from a list of URIs.[email] |
|||||||
Proposal: | |||||||
Resolution:
You raised an issue[0] regarding links in the bibliography sections for XOP[1], MTOM[2] and Representation header[3] specs. This problem has been addressed in the latest editor's copies of these documents[4,5,6][email] |
|||||||
493 | XOP | n/a | meta | Editorial | Closed | Jun Fujisawa | |
Title: On the use of "binary" transfer encoding | |||||||
Description:
In the second example in Section 1.2, "Content-Transfer-Encoding: binary" is specified. It should be mentioned that the value of "binary" cannot be used for many protocols including SMTP which assume 7 bits transfer.[email] |
|||||||
Proposal: | |||||||
Resolution:
The XML Protocol Working Group has closed issue 493 with no action, because the semantics and proper use of Content-Transfer-Encoding are felt to be well-understood and documented by the MIME specifications.[email] |
|||||||
494 | XOP | n/a | meta | Design | Closed | Jun Fujisawa | |
Title: XOP Schema should be normative | |||||||
Description:
Section 1.3, the XML Schema definition of "xop" namespace is marked as non-normative. I think "xop" schema should be normative considering the fact that "rep" schema is also normative.[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP WG rationale to differentiate the normative nature of these namespaces stems from the introduction of XML 1.1 and its impact upon XMLP specifications (See Rec Issue 20 [4]). Since the Representation Header specification and the rep namespace is SOAP specific, only XML 1.0 applies and hence the we define this rep namespace as normative. However, XOP is NOT SOAP specific and thus needs to allow for either XML 1.0 or 1.1. Thus we have defined the xop namespace as non-normative.[email][email] |
|||||||
495 | XOP | n/a | meta | Design | Closed | Jun Fujisawa | |
Title: Suggestion on XOP media type | |||||||
Description:
Section 5, the need for XOP-specific media type (e.g. application/soap_xop+xml) is described. I don't think such an approach is feasible since registering a new media type is a very expensive process. I suggest to use "start-info" parameter of "multipart/related" type instead to indicate that the content is encoded in XOP: Content-Type: multipart/related;type=application/soap+xml; start="<mymessage.xml@example.org>"; start-info="http://www.w3.org/2003/12/xop/include"[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP WG has considered issue 495 which you raised [1]. Your suggestion to use the start-info parameter has already been made in the context of the WG's resolution to issue 470 [2], and the WG is considering this suggestion. Issue 495 duplicates issue 470, and so it will be closed.[email] |
|||||||
496 | MTOM | n/a | meta | Editorial | Closed | Jun Fujisawa | |
Title: Updated reference to requirements | |||||||
Description:
Section 1.2, the reference to "SOAP Attachment Requirements" should be updated to point to "SOAP Optimization Serialization Use Cases and Requirements".[email] |
|||||||
Proposal: | |||||||
Resolution:
You raised an issue, number 496[1] regarding an incorrect reference in the MTOM specification[1]. The editors have corrected the reference to cite the "SOAP Optimized Serialization Use Cases and Requirements" as you suggested.[email] |
|||||||
497 | MTOM | n/a | meta | Editorial | Closed | Jun Fujisawa | |
Title: "mime/multipart-related" media type | |||||||
Description:
Section 4.3.1, the value of "Content-Type" field in the table should be "multipart/related", not "mime/multipart-related".[email] |
|||||||
Proposal: | |||||||
Resolution:
The editors have corrected the error, changing 'mime/multipart-related' to 'multipart/related' as you suggested.[email] |
|||||||
498 | MTOM | n/a | meta | Editorial | Closed | Jun Fujisawa | |
Title: "Content-Transfer-Encoding" header in HTTP/1.1 | |||||||
Description:
Section 4.3.1, it is stated that "Each MIME part that is refered to by xop:Include MUST have a Content-Transfer-Encoding header field". On the other hand, HTTP/1.1 itself does not normally use Content-Transfer-Encoding header field altogether (19.4.5 No Content-Transfer-Encoding). I think more explanation is needed to justify this restriction.[email] |
|||||||
Proposal: | |||||||
Resolution:
Closed with no action[email][email] |
|||||||
499 | Representation | n/a | meta | Editorial | Closed | Jun Fujisawa | |
Title: The content of rep:Data element | |||||||
Description:
Section 2.2.4, the value of a rep:Data element is described as just "a base64 encoded representation" of a Web resource. I think this should be "a base64 encoded representation in the canonical lexical form".[email] |
|||||||
Proposal: | |||||||
Resolution:
During its July 14 meeting, the XMLP WG decided that it was unnecessary to say that the lexical form must be the canonical form, because this header is independent of MTOM. So this will not result in any change to the Representation Header specification.[email] |