This issue list is only for documents that are NOT in Last Call. Please refer to the Last Call issue list (XML source)
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.
id | Status | Spec | Topic | Class | Req | Title |
---|
id | Spec | Req | Topic | Class | Status | Raised By | Owner |
---|---|---|---|---|---|---|---|
1 | Spec | n/a | enc | Design | Closed | Eric Smith | ETF |
Title: Escaping illegal characters | |||||||
Description: Need description of how to escape properties with illegal characters for XML in SOAP. | |||||||
Proposal:
From PaulC: see Subclause 5.1 "Mapping SQL <identifier>s to XML
Names" from ftp://sqlstandards.org/SC32/WG3/Progression_Documents/Informal_working_drafts/wd-xml-2001-06.pdf.
See the proposed resolution. |
|||||||
Resolution: The proposed resolution has been adopted [resolution text]. | |||||||
2 | Spec | n/a | Editorial | Closed | bryan_murray@HP.COM | ||
Title: | |||||||
Description: Follow-up: Whats wrong with attributes? | |||||||
Proposal: | |||||||
Resolution: Dup of issue 1 | |||||||
3 | Spec | n/a | Editorial | Closed | davec@progress.com | marting@develop.com | |
Title: xml schema revision | |||||||
Description: Update syntax of "*" to "unbounded" in SOAP schema according to latest Schema language syntax. | |||||||
Proposal: | |||||||
Resolution: Update completed in SOAP 1.2 WD, July 9, 2001 | |||||||
4 | Spec | n/a | env | Design | Closed | Larry Masinter | Marc Hadley |
Title: Handling DTDs, PIs | |||||||
Description: Lack of clarity and design choices in SOAP's HTTP protocol binding. | |||||||
Proposal:
See the proposed resolution by Marc Hadley. |
|||||||
Resolution:
The resolution text shows stricter replacement text: A SOAP message MUST NOT contain a Document Type Declaration. On receipt of a SOAP message containing a Document Type Declaration, a SOAP receiver MUST generate a fault (see 4.4 SOAP Fault) with faultcode of "Client.DTD". A SOAP message SHOULD NOT contain processing instruction information items. A SOAP receiver MUST ignore processing instruction information items in SOAP messages it receives. See the reply from the originator. After discussion, issue 4 has been closed and a new issue, issue 145 has been opened regarding XML declarations. |
|||||||
5 | Spec | n/a | Editorial | Closed | lars@LARS.COM | marting@develop.com | |
Title: examples | |||||||
Description: Problem in some examples. | |||||||
Proposal: | |||||||
Resolution: Update completed in SOAP 1.2 WD, July 9, 2001 | |||||||
6 | Spec | n/a | Editorial | Closed | marek@ICSD.MOT.COM | marting@develop.com | |
Title: examples and schema | |||||||
Description: Bugs in examples and question of consistency between text and schema. | |||||||
Proposal: | |||||||
Resolution: Update completed in SOAP 1.2 WD, July 9, 2001 | |||||||
7 | Spec | n/a | Editorial | Closed | bernhard.dorninger@SCCH.AT | marting@develop.com | |
Title: xml schema revision | |||||||
Description: Need to update with respect to to latest XML schema spec. | |||||||
Proposal: | |||||||
Resolution: Update completed in SOAP 1.2 WD, July 9, 2001 | |||||||
8 | Spec | n/a | env | Design | Closed | mnot@akamai.com | |
Title: clarify processing model | |||||||
Description: Lack of clarity in SOAP processing model. Various issues? | |||||||
Proposal: | |||||||
Resolution: This is redundant with other issues. [resolution] | |||||||
9 | Spec | n/a | Editorial | Closed | marek@ICSD.MOT.COM | marting@develop.com | |
Title: schema ns declarations | |||||||
Description: Bug in example - need declarations of xsd and xsi namespaces | |||||||
Proposal: | |||||||
Resolution: Update completed in SOAP 1.2 WD, July 9, 2001 | |||||||
10 | Spec | n/a | Editorial | Closed | Tim Sawyer | Editors | |
Title: <xml version> | |||||||
Description: Lack of clarity of when to use XML Version info. | |||||||
Proposal: Duplicate of issue 145. | |||||||
Resolution: Closed with the issue of the Dec 2001 Working Drafts [email] | |||||||
11 | Spec | n/a | Design | Closed | Larry Masinter | Mark Nottingham | |
Title: various | |||||||
Description:
Lack of clarity and design choice in SOAP protocol binding
to HTTP, for example, use of port 80, HTTP status codes,
and use of MUST/SHOULD/MAY is inconsistent.
1st design issue is use of port 80, 2nd design issue is 12, 3rd design issue is 14 |
|||||||
Proposal:
This issue has not been resolved. A summary was prepared for Dinard, but not presented. |
|||||||
Resolution:
Mark Nottingham is going to draft some text to warn about the use of default ports. From the resolution text: We resolved this at our most recent face-to-face, and have inserted text that gives guidelines regarding default ports into what will become the framework for transport bindings. We will incorporate such wording into the HTTP binding itself as its development progresses. |
|||||||
12 | Spec | n/a | bind | Design | Closed | Larry Masinter | Stuart Williams |
Title: HTTP error codes | |||||||
Description: SOAP and HTTP status codes (200 vs. 500 etc.). | |||||||
Proposal:
From Stuart: "This issue has not been addressed at all and is still outstanding." The scope for resolving this issue lies wholly within the definition of the SOAP HTTP binding. Discussion of this issue tends to be polarised and has lead to threads that have become 'exausted' without conclusion eg. [2,3]. I also believe that viewspoints on the resolution of this issue are linked with the viewpoints on the SOAP as a 'cameleon' protocol that takes on the 'character' of what it is bound to or as a 'platform' protocol that provides messaging services that are largely independent of the underlying protocol. This theme also leads to lenghty threads eg. [4] Broadly, I think the resolution of this issue is also tied up with the work of the TBTF although I don't think that TF has an explicit action to propose resoulution for this particular issue. [2] "Issue #12: HTTP Status Codes 500 v 200" [3] "another approach to status codes, etc. in HTTP binding" [4] "A tale of two bindings" Two proposals will be reviewed: proposal 1 and proposal 2. See the new text from Chris. |
|||||||
Resolution: See resolution text from Chris and response from originator, and followup by Chris, and resolution text | |||||||
13 | Spec | n/a | bind | Design | Closed | Charles F McDevitt | Mark Nottingham |
Title: http port number | |||||||
Description: SOAP and HTTP on port 80. | |||||||
Proposal: Duplicate of 11? | |||||||
Resolution:
Mark Nottingham is going to draft some text to warn about the use of default ports. From the resolution text: At our most recent face-to-face, we inserted text into the draft which addresses the issues of the use of default ports. |
|||||||
14 | Spec | n/a | env | Design | Closed | Larry Masinter | Martin Gudgin |
Title: SOAP versioning | |||||||
Description: SOAP versioning model. See also, 66 | |||||||
Proposal: This issue was resolved indirectly by the WG's decision at the Dinard F-T-F to change the SOAP namespace URI and provide a description of how versioning should be achieved ( Appendix C. Version Transition From SOAP/1.1 to SOAP Version 1.2[1] ) | |||||||
Resolution:
At a face-to-face meeting back in February the Working Group decided to change the SOAP namespace URI and describe how versioning from SOAP 1.1 to SOAP 1.2 should be managed. [resolution email] See also the response to the resolution text and the response from the Working Group. |
|||||||
15 | Spec | n/a | Design | Closed | LMM@acm.org | ||
Title: (Dupe) | |||||||
Description: Some protocol requirements labeled as 'MUST' in the SOAP 1.1 spec seem to require implementation etails that have no explicit interoperability requirements. What is the fallback for encodingStyle and confusion about SOAPAction. | |||||||
Proposal: | |||||||
Resolution: Duplicates 11 | |||||||
16 | Spec | n/a | rpc | Design | Closed | Bryan Murray | Frank DeRose |
Title: Void return type | |||||||
Description: The RPC mapping is not clear on how a method with a void
return type and no out arguments should be mapped onto the
SOAP protocol.
Will likely be considered in conjunction with issue 78 This issue should be considered in conjunction with issue 113. |
|||||||
Proposal: | |||||||
Resolution:
Issue 16 [1] is closed as proposed in this message. In a nut shell, the following explanation and the examples below captures the resolution. For more details, read this message. The existence of a return value is signified by the presence of a namespace-qualified accessor named 'result' with the namespace identifier "<http://www.w3.org/2001/12/soap-rpc>" and void returns are not expected to have the above named accessor.[email] |
|||||||
17 | Spec | n/a | Editorial | Closed | Bryan Murray | ETF | |
Title: Section 5 usage | |||||||
Description: Discussion needed as to when and why to use the section 5 encoding. | |||||||
Proposal: | |||||||
Resolution:
A) Change the introductory text in section 2 from "The SOAP data model represents information as a graph of typed nodes. The type system used in the SOAP data model is a generalization of the common features found in type systems in programming languages, databases and semi-structured data. A type is either a simple (scalar) type or is a compound type constructed as a composite of several other typed parts. Examples of simple types are "string," "integer," enumeration, etc. Compound types are described as follows:" To "The SOAP data model represents information as a graph of typed nodes. The type system used in the SOAP data model is a generalization of the common features found in type systems in programming languages, databases and semi-structured data. The purpose of the data model is not to introduce a programming model in SOAP but rather to provide a mapping of non-XML based instance data to some wire representation. It is important to note that use of the SOAP data model and the SOAP data encoding is optional. Applications which already model data in XML, for example using W3C XML schema, may never have any need for using the SOAP data model. Because of the optionality of using the SOAP data model and encoding, it is NOT a requirement to implement it as part of a SOAP node. A type is either a simple (scalar) type or is a compound type constructed as a composite of several other typed parts. Examples of simple types are "string," "integer," enumeration, etc. Compound types are described as follows:" B) Change first paragraph in part 2, section 3 from "SOAP encoding describes how to serialize instances of data that conform to the data model described in 2 The SOAP Data Model for inclusion in SOAP messages." To "SOAP encoding describes how to serialize instances of data that conform to the data model described in 2 The SOAP Data Model for inclusion in SOAP messages. Note that nothing precludes the specification of different encodings based on other data models, or indeed that make different use of the SOAP data model. The SOAP encodingStyle attribute information item (see SOAP Encoding Attribute) can be used to indicate the encoding used." C) The last part of the edit is to remove the paragraph: "Use of the data model and encoding style described in this section is encouraged but not required; other data models and encodings can be used in conjunction with SOAP (see SOAP Encoding Attribute)." as we already address this in section 2.[email] |
|||||||
18 | Spec | n/a | env | Design | Closed | Henrik Frystyk Nielsen | ETF |
Title: "top-level" is unclear | |||||||
Description:
Should multiref be top level or inline? Refer also to issue 121 for a more detailed description. |
|||||||
Proposal:
This issue is a duplicate of issue 121. When closing the issue, get back to Paul Kulchenko, the originator of issue 121 as well. See also the summary of the SOAPBuilders discussion. |
|||||||
Resolution: Hi, the WG has decided to close the issue #18 with the resolution as presented in this email, generally by removing the terms "top-level of serialization" and "independent elements" and thus also allowing embedded multiref elements. | |||||||
19 | Spec | n/a | fault | Design | Closed | Bryan Murray | Henrik Frystyk Nielsen |
Title: Ns of Fault children | |||||||
Description: The SOAP spec currently does not require any namespace for the children elements of the Fault element; namely, faultcode, faultstring, detail, and faultactor. These elements are therefore in the default namespace. | |||||||
Proposal:
See email from Henrik: Reporters comment: Certainly, if the consensus is to leave the children of SOAP Fault unqualified, that is what should be done. I am surprised that given a chance to fix this potential problem that more people are not interested in doing so. Faults are an area that is likely to be fairly localized in most existing implementations and would not be difficult to change. Work needs to be done just to adapt to the new namespace, why not add a namespace to these 4 elements? My understanding is that it is likely there will be additional changes to the spec before it transitions from a working draft to a proposal, this would be yet another small change. Henrik's proposal: It seems that other than convention there is no strong argument for why using unqualified sub-elements breaks or limits what one can do in any way. |
|||||||
Resolution: The Working Group has decided not to change the specification regarding this matter. See the resolution text and the add-on to the resolution text. | |||||||
20 | Spec | n/a | enc | Design | Closed | sjm@APTEST.COM | pcotton@microsoft.com |
Title: clarify schema usage | |||||||
Description:
Propose to have 'xsd:string' as the default type for the
standard encoding style and how schemas are to be used
First, we will tackle point 2. |
|||||||
Proposal: | |||||||
Resolution: The issue originator agrees that his original issue was actually about the XML Schema schemaLocation attribute rather than XMLP/SOAP, see email (member-only). | |||||||
21 | Spec | n/a | env | Design | Closed | jlapp@WEBMETHODS.COM | |
Title: packaging app payloads | |||||||
Description: Related issues regarding the SOAP messaging model and how it works with packaging | |||||||
Proposal: | |||||||
Resolution: See the resolution text. | |||||||
22 | Spec | n/a | bind | Design | Closed | Henrik Frystyk Nielsen | Henrik Frystyk Nielsen |
Title: SOAPAction header | |||||||
Description: There is nothing that says what to do in the HTTP protcol binding if there is a SOAPAction header field but no SOAP in the HTTP request entity body | |||||||
Proposal: See proposal | |||||||
Resolution: The Working Group decided during the September 2001 face-to-face meeting that, whether a SOAPAction header is presence or not, a SOAP Client fault must be generated if the SOAP message is missing [resolution text]. | |||||||
23 | Spec | n/a | Design | Closed | Marc Hadley | ||
Title: (Dupe) | |||||||
Description: Be more specific when and when not PIs and the like is allowed. Duplicates issue 4 | |||||||
Proposal: | |||||||
Resolution: | |||||||
24 | Spec | n/a | env | Design | Closed | erikc@microsoft.com | David Fallside |
Title: allow same ns for mutiple headers | |||||||
Description: It should be allowed to have multiple headers using the same namespace (multiple signatures for example) in a single SOAP message. The current SOAP envelope schema doesn't allow this | |||||||
Proposal:
The SOAP envelope schema defines the type for the Header element as having a content model of: <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> This allows multiple qualified elements from any namespace except http://www.w3.org/2001/06/soap-envelope to appear. |
|||||||
Resolution: The current specification already allows that. See acknowledgement by the originator. | |||||||
25 | Spec | n/a | env | Design | Closed | Yves Lafon | Hugo Haas |
Title: Status of trailers | |||||||
Description: What is the status of footers/trailers? The SOAP/1.1 spec is somewhat ambiguous on the matter as it allows "other stuff" after the body but doesn't say what to use it for or what the processing model is. | |||||||
Proposal: Trailers will be removed from the specification, with a note saying that we have done so to let a chance to people who really want it to let us know. | |||||||
Resolution: [resolution email] Trailers have been removed from the specification, and an editorial note has been inserted to warn people about the removal of trailers. | |||||||
26 | Spec | 400 | Design | Closed | pcotton@microsoft.com | ||
Title: (Req Met) Data encapsulation and representation are orthogonal | |||||||
Description:
[email]
SOAP/1.1 provides a data model and a proposed serialization
of that model using the encoding provided in section 5
[1]
. Both the data model and the data serialization is
orthogonal to the data encapsulation (the SOAP envelope
[2]
). In
[1]
it is stated that the two are orthogonal:
Use of the data model and encoding style described in this section is encouraged but not required; other data models and encodings can be used in conjunction with SOAP (see section 4.1.1). The SOAP envelope provides a mechanism in form of the "encodingStyle" envelope attribute [3] that allows other data models and data serialization mechanisms to be used, |
|||||||
Proposal: Requirement Met | |||||||
Resolution: The WG agrees with the commentator that the requirement is met for the reasons given | |||||||
28 | Spec | 401 | Design | Closed | pcotton@microsoft.com | ||
Title: (Req Met) Data representation must support XML Schema simple and complex types | |||||||
Description:
[email]
SOAP/1.1 adopts all simple types defined by XML Schema as
described in
[4]
:
For simple types, SOAP adopts all the types found in the section "Built-in datatypes" of the "XML Schema Part 2: Datatypes" Specification, both the value and lexical spaces. The SOAP/1.1 data model supports the use of XML schema complex types although it does not support the use of attributes for carrying instance values. The reason is that the SOAP/1.1 serialization mechanism reserves attributes for book keeping of the serialization and does not allows the application to otherwise use attributes. Therefore, XML instances using attributes for carrying instance data do not follow the SOAP serialization. There are two ways around this: generate a schema as described in the comment of R402 or not to use the SOAP serialization model. As one of the goals of the SOAP serialization is to limit the ways instance data can be encoded, the limitation of attributes is not considered as a disadvantage. |
|||||||
Proposal: Requirement Met | |||||||
Resolution: SOAP/1.1 supports simple types and support complex types with the exception of attributes which are reserved for the SOAP serialization. The perceived benefit of this limitation is that it provides a simpler mapping to common programming language constructs. It is therefore judged that this requirement is met given the stated limitation. | |||||||
29 | Spec | 402 | enc | Design | Closed | Paul Cotton | ETF |
Title: Exist non-serialisable data models? | |||||||
Description: [email] SOAP/1.1 states that given any data model that can be expressed using the SOAP/1.1 data model consisting of simple types, complex types, and references, it is possible to create an XML schema representing that model. Next, given a particular instance of values (for example a graph) expressed using that XML schema, it is possible to create an XML instance representing those values. This XML instance is what is being transferred within a SOAP message. The recipient of a SOAP message can given the XML schema and the XML instance recreate the original value (for example a graph) | |||||||
Proposal: The current SOAP/1.1 model seems to be capable of
representing directed graphs as well as object graphs and
enable a recipient to deserialize an XML instance to recreate
those graphs. It is not clear whether there are other data
models that potentially are interesting to serialize but not
representable within the SOAP data model.
See discussion thread started by PaulC. |
|||||||
Resolution:
Serialisations of non-syntactic data models can be transported in the envelope of SOAP messages. For example, RDF graphs can be transported using RDF's XML encoding, and MOF/UML models can be transported using an XMI encoding. We have no evidence of non-syntactic data models that cannot be transported using an XML serialisation.[email] |
|||||||
30 | Spec | 403 | enc | Design | Closed | Paul Cotton | ETF |
Title: Refs to data outside serialisation | |||||||
Description: [email] The SOAP/1.1 encoding uses the "id" and "href" attributes to name and refer to resources or sub-parts of resources. The format of the href attribute is of type "uri-reference" as defined by XML schema. The "id" attribute is of type "ID" as defined by XML/1.0. There are no restrictions on the value of a URI used as value in a href attribute. | |||||||
Proposal: SOAP/1.1 covers this requirement although it is not explicitly stated that URIs can in fact point to anything. | |||||||
Resolution: See resolution email | |||||||
31 | Spec | 404 | Design | Closed | pcotton@microsoft.com | ||
Title: (Req Met) Arrays, nested | |||||||
Description:
[email]
Comment: The SOAP/1.1 data model defines an array type
[5]
:
SOAP arrays are defined as having a type of "SOAP-ENC:Array" or a type derived there from (see also rule 8). Arrays are represented as element values, with no specific constraint on the name of the containing element (just as values generally do not constrain the name of their containing element). as well as the encoding mechanism defines a serialization of that array type:The representation of the value of an array is an ordered sequence of elements constituting the items of the array. Within an array value, element names are not significant for distinguishing accessors. Elements may have any name. and can be nested:Arrays can contain elements which themselves can be of any type, including nested arrays. |
|||||||
Proposal: Requirement Met | |||||||
Resolution: The WG agrees with the commentator for the reasons stated. | |||||||
32 | Spec | 307 | meta | Design | Closed | David Ezell | Stuart Williams |
Title: Support usage scenarios (simple deployment) | |||||||
Description: [email] It cannot be proven that SOAP1.1 would not address this requirement; however, the requirement calls out usage scenarios as tools to prove suitability. Since the usage requirements themselves are under consideration, we can only suggest that the XML Protocol R307 will help outline requirements which are more widely "suitable" than those used in the design of SOAP1.1, and further suggest that SOAP1.1 might fall short of fulfilling these requirements. More specifically, SOAP1.1 has only limited usage scenarios, and as such falls short of R307. | |||||||
Proposal:
From Marwan: The R 307 is to insure that SOAP 1.2 is suitable for
widespread use across organizational boundaries. This implies that the
complexity of the SOAP 1.2 specifications is kept to a minimum.
I think we all agree that SOAP 1.2 is a simple protocol, given that there exist over 46 implementations. From 14 November 2001 teleconference: Stuart Williams will produce resolution text. |
|||||||
Resolution: Work currently in progress [2] illustrates how each of these scenarios may be realised using SOAP 1.2 and therefore demonstrate the suitability of SOAP 1.2 for use across organisational boundaries. [resolution text] | |||||||
33 | Spec | 308 | meta | Design | Closed | David Ezell | TBTF |
Title: Support modularity/layering | |||||||
Description: [email] The SOAP1.1 specification succeeded to some extent in supporting modularity, especially modularity in terms of unforeseen architectural components which can be supported through constructs such as the "Header" and "Body" elements, or in SOAP encoding rules. However, this modularity seems weaker than that specified in the XML Protocol requirements. Further, SOAP1.1 doesn't appear to have much support for "layering". Such support arguably requires a clear architecture, promised in XML Protocol requirements (R300) but missing in SOAP1.1. | |||||||
Proposal: From Marwan: The R 308 argues for modularity and layering in the design of SOAP 1.2. SOAP 1.2 achieves the modularity goal through the use of header blocks and XML namespaces. The SOAP 1.2 binding framework specifies how SOAP 1.2 binds to different transport protocols such as HTTP, HTTPS, SMTP, etc. Also, SOAP 1.2 makes no assumptions with regards to the protocol used for transport. (Except for SoapAction) | |||||||
Resolution:
At the face-to-face in Cannes, the WG voted to accept the proposed resolution described below for issue #33. No changes to the specs are necessary to close this issue.
Modularity at the Top ---------------------The SOAP 1.2 processing model, combined with the ability to add arbitrary extensions to the protocol via the header mechanism, allows spec writers and implementors to cleanly implement pieces of additional functionality in an extremely modular fashion. While it remains the case that some "best practices" documentation with regard to designing SOAP 1.2 "modules" would be useful, the spec itself has been carefully designed to allow for the composition of an almost infinite set of extensions authored by the W3C or any other parties. Modularity at the Bottom ------------------------The Binding Framework in section 5 of part 1 of the spec lays out an architecture for designing transport bindings which may provide for an arbitrary number of "binding features", which may be characterized as semantic extensions to the base SOAP protocol which are provided by the binding/transport. Bindings may be authored for any existing or future underlying protocol, and the framework allows SOAP nodes to utilize arbitrary feaures of any such protocol. It is the opinion of the TBTF that these factors provide for sufficient modularity in the design of SOAP 1.2 to satisfy the requirement, and that issue 33 should therefore be closed. [email] |
|||||||
34 | AM | 300 | meta | Design | Closed | David Ezell | Marwan Sabbouh |
Title: Scope of "semantics" definition in AM, SOAP/XMLP, out-of-scope | |||||||
Description: [email] In SOAP1.1, "1. Introduction", SOAP specifically declines to define an architecture, abstract or otherwise: "SOAP does not itself define any application semantics... or implementation semantics...; rather it defines ... a modular packaging model and encoding mechanisms...". The semantics mentioned are some of the key elements in the abstract models which are being introduced. Clearly, SOAP1.1 doesn't satisfy XML Protocol requirements in this regard. Please note that these semantics are also the focal point of the ongoing "usage scenario" work being done by the WG. Also note that "application" semantics are clearly out of scope (as they are for SOAP1.1), whereas "operational" semantics of a messaging system are in scope. | |||||||
Proposal: From Marwan: The R 300 states that SOAP 1.2 not addresses application semantics. The issue is the "operational semantics" introduced by the AM document. The semantics mentioned in the AM document are in the context of SOAP 1.2 data flow processing and SOAP 1.2 header blocks. This is not to be confused with application semantics, since SOAP 1.2 does not define any application semantics. Find out the status on the AM? | |||||||
Resolution:
The XMLP WG decided to close issue 34 you raised in relation to the Abstract Model WD with no action taken. SOAP 1.2 meets the R300 requirement and does not address application semantics. The semantics mentioned in the AM document are in the context of data flow processing and header blocks, or operational semantics, not application semantics. Further, the AM is now a Working Draft no longer in development. Refinement of the AM is therefore not in the WG's current scope of work.[email] |
|||||||
35 | Spec | 301 | Design | Closed | David_E3@Verifone.Com | ||
Title: (Req Met) Simplicity | |||||||
Description: [email] SOAP1.1 conforms | |||||||
Proposal: Requirement Met | |||||||
Resolution: The XMLP WG believes that the SOAP 1.1 specification meets this requirement. | |||||||
36 | Spec | 301a | meta | Design | Closed | David Ezell | Marwan Sabbouh |
Title: Clarify nature of conformance | |||||||
Description: [email] Since SOAP1.1 defines only a "modular packaging model" and "encoding mechanisms", conformance with SOAP1.1 can be viewed as "validation" conformance (as in DTD or Schema validation). "XML Protocol requirements" is suggesting a more rigorous conformance test which includes semantics defined in in-scope usage scenarios, i.e. certain types of behavior. | |||||||
Proposal:
From Marwan: This issue highlights the need for a conformance draft
document. The WG will make available a draft document that
specifies conformance requirement.
During the 14 November teleconference, the Working Group decided to postpone this issue until a test suite is produced and the issue will then be closed. |
|||||||
Resolution:
The XMLP WG today decided to publish - as part of Last Call - a Test Collection Working Draft. A draft version of this document is today available at [1], and this draft is believed to be close to the version that is published at Last Call. Per the decision documented in the issue list, the WG deicded to postpone resolution of this issue until the WG had decided to publish a document like [1]. With today's decision, the WG believes it has fulfilled the issue.[email] |
|||||||
37 | Spec | 302 | env | Design | Closed | David_E3@Verifone.Com | |
Title: is SOAP extensibility sufficient? | |||||||
Description: [email] SOAP1.1 defines a vocabulary with certain types of extensibility. XML Protocol requirements declare a need for extensibility which supports "decentralized extensibility without prior agreement". It's not clear whether the types of extensiblity in SOAP are adequate for this requirement. | |||||||
Proposal: | |||||||
Resolution: See resolution text. | |||||||
38 | Spec | 304 | meta | Design | Closed | David Ezell | Marwan Sabbouh |
Title: Support usage scenarios (simple apps) | |||||||
Description: [email] A central point of R304 is really that the WG will define certain usage scenarios as in-scope. It is not yet certain whether SOAP1.1 will be adequate for these scenarios. SOAP1.1 does appear to support the RPC flavor of exchange. Other scenarios are not so clear. (See comments in R307). | |||||||
Proposal: From Marwan: The issue here is whether SOAP 1.2 supports in-scope usage scenarios, especially those usage scenarios relating to simple message exchanges on top of SOAP 1.2. The SOAP 1.2 specification makes it easy to exchange one way and two-way messages. It also provided support for more advanced delivery semantics. | |||||||
Resolution: The SOAP 1.2 specification makes it easy to exchange one way and two-way messages. It also provided support for more advanced delivery semantics [resolution text]. | |||||||
39 | Spec | 306 | meta | Design | Closed | David Ezell | Marwan Sabbouh |
Title: Ease-of-deployment | |||||||
Description: [email] SOAP1.1 does not directly address deployment issues; but may indeed satisfy this requirement, with the qualification that it does not address a "full spectrum" of deployment environments. Rather, it addresses the HTTP common web-server/web-browser situation. | |||||||
Proposal:
From Marwan: The issues here are:
1) To ensure that SOAP 1.2 apps work
in a variety of environments. Such environments include
resource-constrained applications.
SOAP 1.2 uses other W3C standards. In this fashion, SOAP 1.2 is
easy to deploy.
2) SOAP 1.2 make use of XML standards where appropriate. Such standards
include XML namespaces, and XML schemas.
See Henrik's comment. |
|||||||
Resolution: SOAP 1.2 make use of XML standards where appropriate. Such standards include XML namespaces, and XML schemas [resolution text]. | |||||||
40 | Spec | 309 | meta | Design | Closed | David Ezell | Mark Baker |
Title: Support resource constrained devices | |||||||
Description: [email] While SOAP1.1 may indeed be adequate for some simple exchanges usable on small systems, hopefully XML Protocol will do a better job of addressing these needs explicitly. | |||||||
Proposal:
From Marwan: The issues here are:
1) To ensure that SOAP 1.2 apps work
in a variety of environments. Such environments include
resource-constrained applications.
SOAP 1.2 uses other W3C standards. In this fashion, SOAP 1.2 is
easy to deploy.
2) SOAP 1.2 make use of XML standards where appropriate. Such standards
include XML namespaces, and XML schemas.
See Henrik's proposal. R309 has been revised during the 14 November teleconference and Mark Baker will write a resolution text. |
|||||||
Resolution: "The ability to use SOAP in a particular environment will vary by the actual constraints, choice of tools, processing model, and nature of the messages being exchanged. The XML encoding of SOAP has dependencies on a minimum number of other specifications (XML Base, XML Schema Datatypes, XML 1.0, and XML Namespaces), none of which has prohibitive processing requirements. SOAP 1.2 also excludes some of XML 1.0's features, which could help lower processing requirements -- see the "Relation to XML section of Part 1, the Messaging Framework. Also, limiting use of SOAP to small messages instead of arbitrarily-sized messages and using a few specific message types instead of implementing generalized SOAP encoding could significantly lower processing requirements." See [email] | |||||||
41 | Spec | 200 | env | Design | Closed | vidur@netscape.com | RPCTF |
Title: no normative target uri | |||||||
Description: [email] [RPC1] The target (program, service or object) URI (TBD) is not mentioned in any normative way in the SOAP envelope. While this does not conflict with the requirements, I believe it's an important (and possibly debatable) decision. This decision precludes sending an RPC invocation through an intermediary that uses different protocol bindings for sending and receiving XP messages. See also mail thread | |||||||
Proposal: | |||||||
Resolution:
The following text is an extract from a proposal produced by Stuart Williams as part of two longer threads that you may want to look though for background. The WG adopted the resolution text with the understanding that it NOT be incorporated into the SOAP 1.2 spec as such although it of course is a permanent reference for the XML Protocol WG issues list. SOAP 1.2 does not provide any normative means to carry the identity ofthe ultimate recipient within a SOAP envelope. SOAP 1.2 does provide a meansto identify the roles that a SOAP header block is targetted to. SOAP 1.2 does not provide any normative means for the expression of a message path with a SOAP envelope. However, it does provide means for the development of SOAP extensions that provides for such expression withinSOAP header blocks. [Work to define a message routing extension for SOAP may be the subject of future WG activity within the W3C.][email |
|||||||
42 | Spec | 200 | rpc | Editorial | Closed | vidur@netscape.com | RPC task force |
Title: clarify "object" and "method" in rpc | |||||||
Description: [email] [RPC2] The SOAP 1.1 spec uses words like "object" and "method" to refer to the end-points of an RPC operation. More generic words (or better qualification of these terms) that do not bias the reader towards expectations of full-fledged object systems on both sides are necessary. | |||||||
Proposal:
1. The terms "object" and "method" are replaced by the terms "service" and "procedure", RPC task force minutes .2. The wording in SOAP 1.2 (and subsequent) clarifies the usage of the terms. |
|||||||
Resolution: Proposal (2) is accepted by the originator of the issue. | |||||||
43 | Spec | 200 | Design | Closed | vidur@netscape.com | vidur@netscape.com | |
Title: | |||||||
Description: [email] [RPC3] The requirements state that the "procedure or method to be called" should also be represented using URI syntax. I believe this is an error in our document - the requirements should place no restrictions on the form of a procedure or method name. | |||||||
Proposal: | |||||||
Resolution: As the initiater and owner of on our XMLP Issues List, I'd like to suggest that we close it. R200 in the XMLP Requirements document states that a procedure or method name in a RPC call must be represented "using URI syntax". The SOAP 1.1 spec states that procedure or method name is represented as a qualified name. While a qualified name is not syntactically equivalent to a URI, it does contain a namespace URI and does, as such, share the same properties with respect to uniqueness. | |||||||
44 | Spec | 200 | rpc | Design | Closed | vidur@netscape.com | jkay@ENGENIA.COM |
Title: correlation when not supported in binding | |||||||
Description:
[email]
[RPC4] Regarding
"2.Enable support for matching response messages to request messages for cases in which matching is not provided by the underlying protocol binding. Section 7.2 states that a correlation ID is an example of the use of a SOAP header element. This does not seem to be a normative part of the specification and no rules are placed on the form of such a transaction ID. "3.The ability to specify the parameters to a call in a request message and the results of a call in a reply messages." Section 7.1 describes how elements in the body of a SOAP envelope can be used to represent parameters in an invocation and return values (and out parameters) in a response."4.Provisions for specifying errors in a reply message (see also 703a and 703b)" Section 7.1 states that a "method fault is encoded using the SOAP Fault element". |
|||||||
Proposal: This was first listed as a transaction ID but the group has recast it as a correlation ID as this seems to be what is meant. | |||||||
Resolution: At the Cannes F2F, the WG decided to accept the following resolution text for issue #44, which arose out of our requirement 200. No edits to the specs are necessary as a result. The TBTF has already defined a message exchange pattern which provides for this type of correlation, and an instance of an HTTP binding which expresses this feature natively in the underlying protocol. We have additionally described the fact that features [4] may be expressed either by binding specifications (either within or outside the purview of the underlying protocol itself) or by SOAP extensions (modules). Although we have not taken on this piece of work directly, we believe we have demonstrated it is possible to write a SOAP module specification which will implement the simple request-response feature via SOAP headers, and therefore provide a transport-neutral realization of the feature. We are confident that this work will occur, and that the results will likely end up in some form "blessed" by an appropriate standards group, however we will not normatively specify such an implementation in SOAP 1.2. [email] | |||||||
45 | Spec | 200 | rpc | Design | Closed | Vidur Apparao | Hugo Haas |
Title: RPC fault codes | |||||||
Description:
[email] [RPC5] Should there be a predefined set of fault codes that apply specifically to RPC? Examples would include errors for missing parameters, out of range values, etc. |
|||||||
Proposal:
See proposal. An RPC fault section has been added to the specification. However, there is still an editorial note saying that the current text conflicts with the definition of SOAP fault codes; clarification has been sought: Marc Hadley will tweak the text in the SOAP faults section to change "this specification" into "part 1 of this specification" and remove the editorial notes. The issue has been reopened due to a comment regarding the text added to the RPC section, namely whether the order of precedence of the rules is ascending or descending. |
|||||||
Resolution:
A section on RPC faults has been added to the RPC convention: The RPC representation introduces additional SOAP fault codes to those described in [1]Fault Codes. The namespace identifier for these SOAP faultcode element information item values is "http://www.w3.org/2001/06/rpc" and the namespace prefix rpc: is used in this section to indicate association with this namespace. [resolution] The specification now specifies that the order of precedence is decreasing. |
|||||||
46 | Spec | 200 | Design | Closed | vidur@netscape.com | fallside@us.ibm.com | |
Title: | |||||||
Description:
[email]
[RPC6]
"Where possible, an attempt will be made to leverage any related work done by the IETF." The SOAP 1.1. spec does not directly reference the IETF work on RPC [ 2 ]. Is the quoted RFC out-of-date? Should more attention have been paid to IETF activity? |
|||||||
Proposal: | |||||||
Resolution: The working group is chartered with taking the SOAP 1.1. specification as its base. The charter also allows the working group to modify that specification to meet its requirements where the existing specification falls short. In cases where such modifications are necessary, the working group may make use of and/or reference IETF technology. To date, the working group has not made any such modifications. However, we are conscious of keeping in touch with the IETF if such modifications are necessary. In particular, we have at least one person on the working group who is aware of relevant IETF work, we invited a presentation on IETF technology at our f2f meeting, and our W3C staff contacts provide an additional link via a regular W3C/IETF co-ordination call. David Fallside, for the XML Protocol Working Group | |||||||
47 | Spec | 201 | enc | Editorial | Closed | Vidur Apparao | ETF |
Title: Data model vs. encoding | |||||||
Description: [email] [RPC7] SOAP 1.1 describes its notion of a "data model" in a section describing an encoding system. The notion of a data model should probably be separated from the actual physical representation. | |||||||
Proposal: [see also discussion thread] SOAP defines in section 5 a datamodel that contains constructs like "struct", "array", "multi-struct", and simple types. The RPC convention in section 7 is cast in terms of the data model and not in terms of a specific representation within the SOAP message. That is, it is possible in SOAP to use another actual representation while still using the SOAP data model as well as using some other data model entirely. We (the WG) makes a note that we should ensure the destinction is made in the XML Protocol spec. We leave it to later to actually decide how we might best tackle this in the design phase. Discussion will take place in email. | |||||||
Resolution: Issue resolved by agreeing to the text proposed as content for the data model section of SOAP part 2. [email] | |||||||
48 | Spec | 202 | Design | Closed | Vidur Apparao | ETF | |
Title: Custom encoding styles | |||||||
Description: [email] The SOAP encodingStyle attribute [5] can be used to used to indicate arbitrary serialization rules within a SOAP message. Section 5 [3] of the specification also states that "use of the data model and encoding style described in [the section describing the default SOAP encoding] is encouraged but not required; other data models and encodings can be used in conjunction with SOAP." | |||||||
Proposal: [see discussion thread] | |||||||
Resolution: See resolution
text.
The issue has bee reclosed again on Tue, 12 Mar 2002, see: You raised an issue to the XML Protocol WG pertaining to the use of custom data encodings in SOAP. The issue was originally closed in November 2001 but during the Feb 2002 F2F meeting the issue was reopened and closed as follows. (i) An implementation of SOAP could be conformant without supporting the SOAP encoding. i.e. Support of the SOAP encoding is optional in implementations. (ii) The SOAP encoding is dependent on the SOAP data model and that the RPC convention is dependent on the SOAP data model *but* *not* the SOAP encoding. (iii) Tests would be provided for implementations claiming conformance with the SOAP encoding. To resolve issue 48 we agreed to the following two actions: (a) Instructing the editors of the SOAP specification to clarify the optional nature of the SOAP encoding in the specification and to clearly describe the dependencies between SOAP, the SOAP data model, SOAP encoding and RPC convention. (b) Instructing the conformance subgroup to include tests for SOAP encoding conformance, but to note the optional nature of the SOAP encoding in the test suite. i.e. SOAP implementations may choose not to implement the SOAP encoding, but if they claim conformance with the SOAP encoding they must pass all of the SOAP encoding conformance tests.[email |
|||||||
49 | Spec | 500 | Design | Closed | john_ibbotson@uk.ibm.com | ||
Title: (Req Met)Support programming models | |||||||
Description: [email] The introduction to the SOAP specification states that: SOAP provides a simple and lightweight mechanism for exchanging structured and typed information between peers in a decentralized, distributed environment using XML. SOAP does not itself define any application semantics such as a programming model or implementation specific semantics; rather it defines a simple mechanism for expressing application semantics by providing a modular packaging model and encoding mechanisms for encoding data within modules. This allows SOAP to be used in a large variety of systems ranging from messaging systems to RPC. Therefore the SOAP 1.1 specification mainly supports R500. Issue: There is a common belief that SOAP is intended for, and only supports the RPC programming model. The XP WG should emphasise the neutrality of its specification to programming models and illustrate its applicability to them via a wide range of use cases. | |||||||
Proposal: Requirement Met | |||||||
Resolution: The WG accepts the commentator's evaluation. Regarding the related-issue mentioned by the commentator, the WG notes that it is adopting use cases and believes these satisfy the issue mentioned. | |||||||
50 | Spec | 501 | meta | Design | Closed | John Ibbotson | TBTF |
Title: Consider bindings other than HTTP | |||||||
Description: [email] The SOAP 1.1 specification defines a binding to HTTP only. Therefore it only partially supports requirement R501. | |||||||
Proposal: From Marwan: The issue is to unsure that SOAP 1.2 supports (but not define) binding to protocols other than HTTP. The SOAP 1.2 Part 1 has a section Transport Binding Framework [2] that describe how SOAP 1.2 may use protocols other than HTTP. [2]: http://www.w3.org/TR/2001/WD-soap12-part1-20011002/ | |||||||
Resolution: At the Feb 2002 FtF, the XMLP Working Group decided to close issue #50, accepting the new SOAP Email Binding as its resolution. [email] | |||||||
51 | Spec | 502 | env | Design | Closed | john_ibbotson@uk.ibm.com | |
Title: support different message patterns | |||||||
Description: [email] The SOAP 1.1 specification partially supports requirement R502. There are no explicit examples in the SOAP 1.1 specification to support this requirement. The XP specification must provide a broader set of patterns and scenarios. | |||||||
Proposal: The XML Protocol Usage Scenarios Working Draft contains some 20 scenarios and patterns illustating the use of SOAP 1.2. The provision of this document resolves the concern of issue 51. [email] | |||||||
Resolution: the SOAP WG has decided to close issue 51 with the proposed resolution. [email] | |||||||
52 | Spec | 503 | Design | Closed | john_ibbotson@uk.ibm.com | ||
Title: (Non-Issue)Group co-ordination | |||||||
Description: [email] Requirement R503 is a procedural requirement placed on the XP WG and is not influenced by the SOAP 1.1 specification. | |||||||
Proposal: Non-Issue | |||||||
Resolution: The WG accepts the commentators assertion that this is not actually an issue. | |||||||
53 | Spec | 504 | env | Design | Closed | John Ibbotson | |
Title: Orthogonal extensions | |||||||
Description: [email] The SOAP 1.1 specification provides a lightweight framework with extensibility via namespace defined header elements. The SOAP Body provides a mechanism for exchanging mandatory information (Section 4.3). This provides only part of the extensibility requirements implied by R504. Therefore the SOAP 1.1 specification partly fulfils R504. | |||||||
Proposal: From John Ibbotson: When this requirement and the resulting issue were generated, it was at a time when the real scope of the WG was being established. It was uncertain whether the WG would define any extension headers in addition to the core specification. The optional parts referred to in the requirement relate to any optional extension header that the WG may have defined. The mandatory part refers to the core specification. In the light of the current WG activities and direction (we are not defining any extension headers), I think the issue is no longer valid and we can remove it from the list. | |||||||
Resolution: The optional parts referred to in the requirement relate to any optional extension header that the WG may have defined. The mandatory part refers to the core specification. In the light of the current WG activities and direction (we are not defining any extension headers), the issue is no longer valid. [resolution text] | |||||||
54 | Spec | 505 | meta | Design | Closed | John Ibbotson | Mark Baker |
Title: How much is "without a priori knowledge"? | |||||||
Description: [email] The SOAP 1.1 specification does not support this requirement. At the minimum, there has to be an implicit assumption that the communicating parties will understand the SOAP protocol. The protocol does not provide a mechanism for submitting a SOAP request to a generic HTTP (or other protocol) server. | |||||||
Proposal: From Marwan: R 505 states that the SOAP 1.2 spec must be suitable for use between communicating parties with no apriori knowledge of each other. This req. is ill worded and should be changed! Typically, two programs needs to agree on the transport binding protocol, method of invocation, encoding, etc. in order for them to communicate successfully! | |||||||
Resolution:
While it is true that not all uses of SOAP meet requirement R505, the specification itself can be used in a manner that meets the requirement. When SOAP is used such that it inherits the semantics of the underlying protocol, and if that protocol provides the necessary a priori agreement, then SOAP also inherits it. This is the case for the default HTTP binding. It is not required there be a priori agreement about the use of SOAP, as HTTP provides the necessary features by which support, or lack thereof, is communicated. Also, SOAP does provide a "mechanism for submitting a SOAP request to a generic HTTP (or other protocol) server", as any HTTP URI can have a SOAP message POSTed to it, and both sender and receiver can coordinate the view of the success or failure of that POST with existing HTTP features. Other protocols that provide similar capabilities will allow SOAP to inherit them when bound in this way.[email] |
|||||||
55 | Spec | 506 | Editorial | Closed | John Ibbotson | ETF | |
Title: Examples needed for encoding/encapsulation | |||||||
Description: [email] The SOAP 1.1 specification partially fulfils this requirement. It provides one mechanism for encapsulation and encoding of data with limited examples of extensibility. The XP specification must broaden these mechanisms via use cases. | |||||||
Proposal: Given that: * The SOAP 1.2 spec provides a modular mechanism by which it is possible to use multiple representations of user data including plain schema based (document literal), using the SOAP encoding provided in part 2, or some other encoding entirely, potentially involving data carried outside the envelope (we at least do not claim to preclude this). * The usage scenario WD [4] contains several examples of encoding data both using document literal and the SOAP 1.2 encoding. * The primer [5] provides several documented examples and use cases of both document literal and the SOAP encoding. would it be reasonable to suggest that we may at the current time cover the call for multiple mechanisms brought forward and close the issue? [email] | |||||||
Resolution: Proposal accepted. [email] | |||||||
56 | Spec | 600 | env | Design | Closed | ohurley@iona.com | |
Title: transport neutrality | |||||||
Description: [email] SOAP 1.1 has an implicit dependency on a synchronous request/response transport protocol to achieve correlation. It has a further implicit dependency on SOAP processor endpoint information being transport protocol endpoint information. | |||||||
Proposal: | |||||||
Resolution:
As a result of the Transport Binding Framework in SOAP 1.2, we have separated out the concept of request/response correlation from a particular transport instance (HTTP) into an abstract "feature", whose specification may be found in the Adjuncts section of our spec. As described in the framework text, features may be implemented in a variety of ways, including but not limited to transport-specific representations thereof. Although we have not gone so far as to define an entirely transport-neutral correlation mechanism (such as might be accomplished with SOAP headers), we believe we have demonstrated that such a mechanism is possible. These aspects of our work have removed the "hard-wired" dependence on HTTP correlation mechanisms.
In answer to the second part of the issue, namely that SOAP processor endpoint information must be transport protocol endpoint information, I would posit that this was never really the case. The "actor" attribute in SOAP 1.1 was defined as an arbitrary URI, just like actors/roles in SOAP 1.2. If I am reading the issue correctly and the problem was with node identifiers (i.e. actors) vs. endpoint identifiers (i.e. transport URLs), I think this distinction has been made even more clear in SOAP 1.2. |
|||||||
57 | Spec | 604 | bind | Design | Closed | Oisin Hurley | TBTF |
Title: Usage scenario over multiple transports | |||||||
Description: [email] Not relevant to SOAP 1.1, so not addressed. | |||||||
Proposal:
From Marwan: The R 604 suggests that there is no info loss when a SOAP
1.2 message is routed over multiple transports. SOAP 1.2 Action Header
may be problematic here, because it is a function of HTTP.
Result of the 14 November teleconference: postponed and assigned to TBTF. |
|||||||
Resolution: This issue is resolved by the SOAP binding to Email, as well as updates to the Transport binding framework text. Within the Transport Binding text, recommendations are given regarding the use of SOAPAction as well as transport based features. [email] | |||||||
58 | Spec | 608 | meta | Design | Closed | Oisin Hurley | TBTF |
Title: Must not preclude security binding | |||||||
Description: [email] Not specifically addressed by SOAP 1.1, although limited extension facilities may be used to help achieve this goal. | |||||||
Proposal: From Marwan: R 608 states that SOAP 1.2 should not preclude bindings to protocol that provides security. The SOAP 1.2 binding framework specifies how to bind SOAP 1.2 to transport protocols. These protocols can include HTTPS and S/MIME. There are SOAP 1.2 implementations that support HTTPS. Using this implementation, you can encrypt part of the SOAP message; e.g. the body and not the header. | |||||||
Resolution: XMLP working group decided to formally close issue 58, accepting the proposed resolution text sent on xml-dist-app@w3.org. [email] | |||||||
59 | Spec | 609 | i18n | Design | Closed | Oisin Hurley | |
Title: Mandate particular character encoding | |||||||
Description: [email] Not specifically addressed. | |||||||
Proposal: | |||||||
Resolution:
The transport binding framework will additionally say, that it is the responsibility of transport bindings to specify how the infoset is being transfered to and reconstituted by the binding at the receiving node. Such a binding, if using XML 1.0 serialization of the infoset, may mandate that a particular character encoding or set of encodings be used. The normative HTTP binding will state that it mandates that the receiver at least supports the UTF-8 and UTF-16 encodings. The indication and negotiation of used character encodings will be done using standard HTTP and XML mechanisms.[email] |
|||||||
60 | Spec | 612 | meta | Design | Closed | Oisin Hurley | Marwan Sabbouh |
Title: Provide HTTP binding | |||||||
Description: [email] A binding to a synchronous request/response protocol is implicit in the SOAP 1.1 specification, so a normative binding to HTTP is not addressed. | |||||||
Proposal: This issue requires SOAP 1.2 to define a normative binding to HTTP. SOAP 1.2 Part 2 [3] does just that! [3] http://www.w3.org/TR/2001/WD-soap12-part2-20011002/ | |||||||
Resolution: SOAP Version 1.2 Part 2 defines a normative binding to HTTP [resolution text]. | |||||||
61 | Spec | 700a | env | Design | Closed | ohurley@iona.com | |
Title: external payload reference | |||||||
Description: [email] This requirement is partially addressed by SOAP 1.1, which provides a SOAP:Header extension element that may be used to add arbitrary XML to a SOAP:Envelope. SOAP 1.1 does not include defined mechanisms to carry and reference payloads outside the SOAP:Envelope, nor does it address carrying non-XML formatted information. | |||||||
Proposal: | |||||||
Resolution:
the WG decided that a document describing an Attachments binding feature: (i) be created by the WG's Transport Binding Task Force (TBTF) during the Last Call review period as part of their work for the WG (ii) be published by the WG although not as a normative part of the specification, and as a document type to be decided. Candidate document types include text document, W3C Note, Internet Draft, etc. (iii) claims to be a first draft of an Attachments feature description. (iv) the description to include the concept of an attachment (e.g. the relation between an attachment and a SOAP envelope, the processing obligation of a SOAP processor to an attachment, etc), what an attachment feature means in the context of our framework, and possibly other topics to be decided (v) must not prejudice any particular attachment scheme such as SOAP with Attachments, DIME, etc.[email] |
|||||||
62 | Spec | 700b | env | Design | Closed | Oisin Hurley | Oisin Hurley |
Title: mU for extensions | |||||||
Description: [email] The SOAP 1.1 mustUnderstand attribute scheme satisfies this requirement for the SOAP:header extension mechanism only. XML Protocol specific extension mechanisms will require a similar attribution to satisfy this requirement. | |||||||
Proposal: From Oisin: This issue I believe to be resolved. The core of the issue was that XMLP extension mechanisms should have a 'mustUnderstand' style of attibute to indicate mandatory processing. I understand this to be the case. | |||||||
Resolution: The core of the issue was that XMLP extension mechanisms should have a 'mustUnderstand' style of attibute to indicate mandatory processing. This is the case for SOAP Headers, which are the XMLP extension mechanism. [resolution text] | |||||||
63 | Spec | 700c | env | Design | Closed | Oisin Hurley | Oisin Hurley |
Title: standard failure for extensions | |||||||
Description: [email] Partially addressed by the simple semantics of SOAP:fault categories | |||||||
Proposal: From Oisin: This is a follow-on issue to 62 and I believe this to also be resolved in the current draft. The core of this issue is a standard failure model for extensions and I think that while we don't have a very rich failure model, having a mustUnderstand code is enough to satisfy this requirement. | |||||||
Resolution: The core of this issue is a standard failure model for extensions and the mustUnderstand fault code is enough to satisfy this requirement. [resolution text] | |||||||
64 | Spec | 701a | env | Design | Closed | ohurley@iona.com | |
Title: envelope specification | |||||||
Description: [email] The SOAP 1.1 Enveloping scheme satisfies this requirement if taken in isolation. Given the context of other XML Protocol requirements and the context of binary content discussions, the SOAP 1.1 scheme may only partially satisfy this requirement. | |||||||
Proposal: | |||||||
Resolution: Resolution text: "The schema for the SOAP envelope describes the outermost syntactical construct or structure within which all other syntactical elements of the message must be enclosed. [resolution email] | |||||||
65 | Spec | 701b | env | Design | Closed | ohurley@iona.com | |
Title: define processing model | |||||||
Description: [email] Is only slightly addressed by the concept and categorisation of faults and so is not satisfied by the SOAP 1.1 specification. | |||||||
Proposal: | |||||||
Resolution: "SOAP 1.2 does define a processing model." see resolution email | |||||||
66 | Spec | 702 | env | Design | Closed | Oisin Hurley | Martin Gudgin |
Title: xmlp revision mechanism | |||||||
Description: [email] SOAP 1.1 provides simple envelope versioning through the use of XML namespaces and provides a specific faultcode for a failure in this area. As such it may be said to satisfy this requirement, but in a very unsophisticated manner. See also 14 | |||||||
Proposal: Same resolution as issue 14. | |||||||
Resolution: At a face-to-face meeting back in February the Working Group decided to change the SOAP namespace URI and describe how versioning from SOAP 1.1 to SOAP 1.2 should be managed. [resolution email] | |||||||
67 | Spec | 703a | fault | Design | Closed | ohurley@iona.com | |
Title: convey error information | |||||||
Description: [email] SOAP 1.1 provides a fault entity, but also has an implicit dependence on HTTP for delivery, so it partially satisfies this requirement. Again, it is in a fairly unsophisticated manner as the faultcode semantics are limited. | |||||||
Proposal: Issue 67 [1] "convey error information" appears to partly duplicate of Issue 102 [2] "Clarify rules for delivering fault messages". The resolution of issue 102 [3], that places a responsibility on MEPs specifications to define the disposition of faults during their operation, largely closes Issue 67. The protocol binding framework makes provision for the reporting of errors arising from an operational failure of a protocol binding or its underlying protocol to the local SOAP node. [email] | |||||||
Resolution: During the W3C XMLP WG Telcon on 6th March 2002 [1] the WG agreed to close Issue 67 by accepting the proposed resolution of the issue. [email] | |||||||
68 | Spec | 703b | env | Design | Closed | ohurley@iona.com | |
Title: convey status information | |||||||
Description: [email] Not satisfied in SOAP 1.1 | |||||||
Proposal: | |||||||
Resolution: [email] - The WG has decided to close this issue with the resolution that we don't call out or otherwise define any status information and so status information is handled as any other information that is not fault information. The group believes this covers the requirement. | |||||||
69 | Spec | 803 | bind | Design | Closed | Mark Nottinghan | |
Title: HTTP binding bias | |||||||
Description: [email] The relationship between the transport binding and message is implied in "Using SOAP in HTTP". SOAP doesn't have a firm conception of a protocol binding or the requirments placed upon it - HTTP is assumed. | |||||||
Proposal:
From Mark: I think we're on the road to satisfying this with the specification of a binding framework, combined with the separation out into 'adjuncts'. I think we should wait until the binding framework is more concrete before we close this, but based on what I know about the direction we're going in, I consider this satisfied. |
|||||||
Resolution: The XML Protocol WG has decided to close issue 69 by noting that the SOAP 1.2 Working Draft now contains a Binding Framework section that describes an abstract framework that can be used to define arbitrary transport bindings. By providing the Framework, the WG believes it has resolved the issue and its underlying Requirement 803. [email] | |||||||
70 | Spec | 811 | env | Design | Closed | Mark Nottingham | |
Title: Define processing intermediaries | |||||||
Description: [email] SOAP accommodates processing intermediaries, but does not define them. See also R806 and R808. | |||||||
Proposal:
See the proposed resolution text. |
|||||||
Resolution:
The definition of SOAP Intermediary in the glossary addresses this issue. [resolution text] |
|||||||
71 | Spec | 806 | env | Design | Closed | Mark Nottingham | Hugo Haas |
Title: Identifying blocks for processing | |||||||
Description: [email] SOAP allows targeting through the "actor" attribute. The value of the attribute may be underspecified; currently, there is no standard way to refer to intermediaries with a URI. Additionally, it may be desireable to target an XP Block by means other than direct reference or 'hop-by-hop', as described. Also, SOAP's processing model does not dictate the order in which multiple headers should be processed, if targetted at the same processor. | |||||||
Proposal:
See Hugo's tracking on August 27th. Mark's clarification: This issue has not been resolved. The actor 'next' is defined. However, the abstract model also suggests 'final' and 'none' Others, such as 'any' have been discussed. Mark Nottingham will draft some text for the definition of the 'none' actor. |
|||||||
Resolution:
During the 29 August 2001 telcon, it was decided that the third part of the issue (re. the order in the processing model) was already addressed in the specification. The Working Group decided during the September 2001 face-to-face meeting to create a "none actor". See resolution text. |
|||||||
72 | Spec | 808 | Design | Closed | mnot@akamai.com | ||
Title: (Req Met)PI generation of error/status messages | |||||||
Description: [email] SOAP provides error and status reporting through SOAP Faults The 'faultactor' subelement satisfies this requirement. See notes in R806 regarding the value of this element. Also, it should be noted that the mechanism for communicating a SOAP Fault is necessarily transport binding-dependent. | |||||||
Proposal: Requirement Met | |||||||
Resolution: The WG accepts the commentators assertion that the 'faultactor' element satisfies this requirement. | |||||||
73 | Spec | 802 | env | Design | Closed | Mark Nottingham | Mark Nottingham |
Title: Identifying blocks for i/mediaries | |||||||
Description: [email] SOAP does not explicitly address this requirement, but it should be addressed by the 'actor' attribute, in that XP Blocks which were not targetted could be skipped over, depending on the processor implementation. | |||||||
Proposal:
From Mark: This issue is a little fuzzy, in that there was debate of the meaning of 'processing'. Despite this, this requirement seems to be met by the current envelope and processing model; suggest it be considered resolved. |
|||||||
Resolution: From the resolution text: The working group has closed issue 73, as the requirement is satisfied by the current design of SOAP, in particular the Header/Body distinction. | |||||||
77 | Spec | n/a | env | Design | Closed | Andy Neilson | Mark Nottingham |
Title: handling midstream errors | |||||||
Description: What happens when a response turns bad midstream? What are the possible ways to handle this? | |||||||
Proposal:
This issue seems to be a combination of issue 12 (status codes) and clarification of when it's appropriate to use a Fault. |
|||||||
Resolution: After discussion, the Working Group has decided that the text in the current draft is sufficient to address this problem without specifically calling it out, as SOAP requires Faults to be represented in certain ways, and for message processing to occur in the manner specified. SOAP applications which encounter recoverable errors (e.g., a missing row in a database) should define conventions that indicate them without the use of Faults. [resolution text] | |||||||
78 | Spec | n/a | rpc | Design | Closed | sfell@streetfusion.com | Frank DeRose |
Title: ordering of structs | |||||||
Description: [
email
] Clarification on how to use the SOAP root attribute. See
thread on soapbuilders
Will likely be considered in conjunction with issue 16 |
|||||||
Proposal: [email] | |||||||
Resolution:
We rephrase the long paragraph in section 3.7 into: >>The root attribute information item is used to mark element information items that are true roots of a serialised graph. Element information items that are true roots MUST be labelled with a root attribute information item with a logical value of "true". If the attribute information item is missing or has the value of "false", the element is not a true serialization root.<< In section 4.1 - RPC and SOAP Body says that "the invocation is viewed as a single struct" and "the response is viewed as a single struct". We will make it more explicit: >>The invocation and response structs are the only true serialization roots.<<[email] |
|||||||
79 | Spec | n/a | Design | Closed | |||
Title: | |||||||
Description: [ email ] Use of actors, mustUnderstand, and faults. Part of a long discussion on soapbilders | |||||||
Proposal: | |||||||
Resolution: Split into issues 99 and 100 | |||||||
80 | AM | n/a | Design | Closed | skw@hplb.hpl.hp.com | wsadiq@vitria.com | |
Title: | |||||||
Description: The AM doc states that the relationship between targeting XML protocol blocks and XML message routing is still an area of significant debate | |||||||
Proposal: | |||||||
Resolution: The first two issues are called out in the AM doc issues section, the group felt these issues needed to be brought back to the WG, they are unassigned. Issue 1 refers to the debate about the role of targeting blocks/processing WITHIN the envelope, and whether routing is a function handled within the envelope or not. How does routing happen? Waqar - commented, volunteered. See response | |||||||
81 | AM | n/a | Design | Closed | skw@hplb.hpl.hp.com | jones@research.att.com | |
Title: | |||||||
Description: The AM doc states that the terms XML protocol module and XML protocol handler continues to be problematic along with the model for mechanism to dispatch XML protocol blocks to the appropriate entity. | |||||||
Proposal: | |||||||
Resolution: Discussion from last week may have resolved issue 2. He will clarify enough for AM spec to reach publication. | |||||||
82 | Spec | n/a | env | Design | Closed | Mark Jones | Mark Jones |
Title: Header/block distinction | |||||||
Description: [email, email, email, email, email, email, email] Not so much an AM issue as a design issue, but there are threads having to do with whether the design should syntactically separate Header and Body blocks or allow them to be intermingled as they are generated (e.g., in a common Blocks element). SOAP does the former; there were several messages that offered support for the latter. The bifurcation of blocks has consequences for serialization of inserted blocks by multiple handlers in a sender or in a receiver for the reply message; buffering may be required. There are usage scenarios (e.g., S21) which emphasize the need for incremental generation and processing of messages, particularly for memory-limited devices. On the other hand, R802 says that intermediaries should be able "to locate and process blocks intended for them without processing the entire message". This might imply a Header and Body organization or some other mechanism for locating appropriate blocks. | |||||||
Proposal: Requirements R307 and R308 call for simplicity, which would argue for eliminating a distinction between header and body blocks if one is not warranted. This is particularly true if that distinction poses a problem for resource-constrained devices, which requirement R309 reminds us to consider and which are implicated in usage scenario S21. Furthermore, the Abstract Model currently makes no semantic distinction between header and body blocks. The primary support for maintaining a distinction comes from requirement R802 and existing practice in SOAP 1.1. A workaround exists for memory-limited handlers/processors that need to produce intermingled header and body blocks. The body blocks can instead be produced as header blocks and then referenced in a later small body block. This has the drawback that the large body blocks in the header may not be easily skipped by intermediaries, which re-raises the R802 problem again. It is recommended that the design activity reconsider the SOAP 1.1 syntax for header and body blocks in light of the above issues. | |||||||
Resolution:
On today's conference call, the XMLP WG voted to close issue 82 [1] according to the resolution proposed in [2]. [email] |
|||||||
83 | AM | n/a | Design | Closed | NAKAMURY@jp.ibm.com | vidur@netscape.com | |
Title: | |||||||
Description: [ email , email ] The AM doesn't say anything about message construction. For example, when a handler inserts a block, can it specify where to insert it in the message? Also, the XMLP_UnitData.send primitive takes a Message as an argument. Must the message be fully formed in advance or can it be generated on the fly? | |||||||
Proposal: | |||||||
Resolution: See response on list | |||||||
84 | AM | n/a | Design | Closed | moreau@crf.canon.fr | jones@research.att.com | |
Title: | |||||||
Description: [ email ] Suggestion to make discussion in section 4.2 more abstract | |||||||
Proposal: | |||||||
Resolution: | |||||||
85 | AM | n/a | Editorial | Closed | moreau@crf.canon.fr | jones@research.att.com | |
Title: | |||||||
Description: [ email , email ] Editorial suggestions regarding figures and textual ordering. | |||||||
Proposal: | |||||||
Resolution: Mark volunteers to take this issue, STUART may have already have a resolution | |||||||
86 | AM | n/a | Design | Closed | Chris Ferris | Henrik Frystyk Nielsen | |
Title: Recipients of intermediates' faults | |||||||
Description: [email, email] Should faults that arise from blocks which are introduced by intermediaries be reported to the intermediary or to the sender? | |||||||
Proposal: Paul/Henrik to write up an explanation of the "out of scope" resolution to this issue | |||||||
Resolution:
The XMLP WG decided to close issue 86 you raised with no action taken. The AM is now a Working Draft no longer in development. Refinement of the AM to detail fault handling in intermediate scenarios is therefore not in the WG's current scope of work.[email] |
|||||||
87 | AM | n/a | Editorial | Closed | Chris Ferris | Stuart Williams | |
Title: Clarify correlation message reference parm | |||||||
Description: [email, email, email, email, email, email] There is unclarity in the definition of the Correlation.MessageRef parameter and how to interpret it. | |||||||
Proposal: Stuart to perform editorial clarification for .messageref parameter desc. | |||||||
Resolution:
The XMLP WG decided to close issue 87 with no action taken. The AM is now a Working Draft no longer in development. Refinement of the AM is therefore not in the WG's current scope of work. |
|||||||
88 | AM | n/a | Editorial | Closed | chris.ferris@east.sun.com | jones@research.att.com | |
Title: | |||||||
Description: [ email , ] Section 4.2 needs to more precisely define what it means to "process" a block. Also, clarify "terminate processing" in concept #7. | |||||||
Proposal: | |||||||
Resolution: | |||||||
89 | AM | n/a | Editorial | Closed | Chris Ferris | Marc Hadley | |
Title: Reconcile correlation descriptions | |||||||
Description: [email, email, email, email] Is the correlation in section 5 the same as in section 3? Section 5.3 needs to clean up the description of OP, MSG and ERR. The nesting of bindings needs to be described more fully. | |||||||
Proposal: | |||||||
Resolution:
The XMLP WG decided to close issue 89 you raised with no action taken. The AM is now a Working Draft no longer in development. Refinement of the AM is therefore not in the WG's current scope of work.[email] |
|||||||
90 | AM | n/a | Design | Closed | Ray Denenberg | Ray Whitmer | |
Title: Is response required for UnitData? | |||||||
Description: [email, email] Is a "response-required" parameter needed for UnitData? | |||||||
Proposal: David/Mark call for clarification on this issue, it is from Ray. Ray - I felt that it might be a weakness in the model to abandon guidelines for request/response actions to model RPC and other messaging patterns, there is no explicit RPC support through the description of the unitdata primitives only, aside from correlation and causality (one message arises as a result of another.) This does not encompass the deterministic nature of RPC, where if you send a request, you MUST have a CORRESPONDING RESPONSE, or you have no RPC. The XMLP layer does not have any way of requiring a resultant message. Henrik - you could have semantics requiring a non 1-to-1 message exchange requirement, or any open ended requirement structure. It would be a high level function to REQUIRE resultant messages. Ray - the XMLP layer is not "aware" of such requirements, it does not know. Henrik - the semantic of the application knows. Ray - then XMLP does not know whether to keep the connection open, for example. David F. - Doesn't RPC sit "above" XMLP? Henrik - we decided that RPC is a module, no? David F. - who will own this? Ray - I can own this. | |||||||
Resolution:
The XMLP WG decided to close issue 90 you raised with no further action. The Abstract Model is now a Working Draft no longer in development, with further refinement of the AM not in the WG's current scope of work. Further, the XMLP_UnitData Operation construct predated MEPs and is not incorporated into SOAP 1.2, which does not define the protocol service layer.[email] |
|||||||
91 | AM | n/a | Editorial | Closed | NAKAMURY@jp.ibm.com | jones@research.att.com | |
Title: | |||||||
Description: [ email ] Section 4 variously talks about blocks targetted at handlers and at processors. The terminology needs to be reconciled within the document and with the revised glossary definitions approved in the April 4 telcon. | |||||||
Proposal: | |||||||
Resolution: | |||||||
92 | AM | n/a | Editorial | Closed | NAKAMURY@jp.ibm.com | jones@research.att.com | |
Title: | |||||||
Description: [ email ] How does Handler d at an intermediiary in Figure 2.1 get invoked? It is not associated with any block in the message. | |||||||
Proposal: | |||||||
Resolution: | |||||||
93 | Spec | n/a | env | Design | Closed | Paul Kulchenko | Doug Davis |
Title: mU at client | |||||||
Description: [email] mustUnderstand on client side. See also thread | |||||||
Proposal:
See Doug's proposal. |
|||||||
Resolution: See the resolution
text:
It is believed that the processing model clearly states what the client should do - it must process the incoming message (from the server) according to the SOAP processing model - which will include noticing and correctly processing MU headers. If there is an error then a Fault MUST be generated - the spec is, for the most part, silent on what happens with the Fault since that will be a choice based on the application semantics and the Transport Binding. The spec does talk about it in specific cases, like the server side of RPC [2], but you asked about the client side. 8-) |
|||||||
94 | Spec | n/a | Editorial | Closed | frystyk@microsoft.com | marting@develop.com | |
Title: typos | |||||||
Description: Typo in example in SOAP/1.1 section 5.4.2 | |||||||
Proposal: | |||||||
Resolution: Update completed in SOAP 1.2 WD, July 9, 2001 | |||||||
95 | Spec | n/a | bind | Design | Closed | Henrik Frystyk Nielsen | Henrik Frystyk Nielsen |
Title: SOAPAction header | |||||||
Description: [email, email, email] Use of the SOAPAction Header field. There has been several discussion on the lists regarding the use of SOAPAction header field. This issue is to ensure that we clarify the use of the header field in the spec | |||||||
Proposal: See proposal. | |||||||
Resolution: The Working Group decided during the September 2001
face-to-face meeting to integrate the following text
in the specification:
(part 2) 6.1.1 The SOAPAction HTTP Request Header Field Some SOAP Receivers using this binding might need certain information to be readily available within the underlying protocol. This binding uses the SOAPAction HTTP request header field to supply this information. soapaction = "SOAPAction" ":" <"> URI-reference <"> The value of this request header field can be any URI reference, including absolute URIs and relative URIs, in which case it is interpreted relative to the Request-URI. SOAPAction's presence in this binding's request messages is OPTIONAL. SOAP Receivers MAY use it as a hint to optimise processing, but SHOULD NOT require its presence in order to operate. If a SOAP Receiver does require SOAPAction's presence in order to operate, it MUST respond to requests which either contain an unrecognised SOAPAction header value or do not contain a SOAPAction header with a 427 "SOAPAction Required" HTTP response status code. Such response messages MAY contain a 'Required-SOAPAction' HTTP response header field, whose value is the URI which can be used in the SOAPAction request header field to re-submit the request. req-soapaction = 'Required-SOAPAction' ":" <"> URI-reference <"> Support for SOAPAction is OPTIONAL in implementations. Implementations SHOULD NOT generate or require SOAPAction UNLESS they have a particular purpose for doing so (e.g., a SOAP Receivers specifies its use). See resolution text and its explanation. |
|||||||
96 | AM | n/a | Design | Closed | Stuart Williams | ||
Title: Map AM to SOAP 1.1, Reqs | |||||||
Description: The Subgroup feels that the Abstract Model should be mapped against the various scenario's presented in the requirements document and against the SOAP 1.1 and SOAP with Attachments Notes. This work is in progress but has not been completed. | |||||||
Proposal: | |||||||
Resolution:
The XMLP WG decided to close issue 96 you raised with no further action. The AM is now a Working Draft no longer in development. Mapping the XMLP requirements, SOAP 1.1 and SWA to the AM is therefore not in the WG's current scope of work.[email] |
|||||||
97 | Spec | n/a | enc | Design | Closed | Andrew Layman | ETF |
Title: echo base64 | |||||||
Description: [email] Remove discrepancy between SOAP/1.1's description of base64 encoded binary data (the comment regarding line length) and the latest XML Schema spec | |||||||
Proposal: | |||||||
Resolution: SOAP Encoding embraces base64 type as defined in XML Schema - Datatypes together with the errata to the document. [email] | |||||||
98 | Spec | 811 | env | Design | Closed | texin@progress.com | david.clay@oracle.com |
Title: content based routing | |||||||
Description: [ email ] Content based routing of unormalized payloads. For example, if it is needed to specify that any payload that includes the term FOO-BAR be sent to a particular location, and if the payloads can contain unnormalized variations of FOO-BAR, then some of the payloads may not be routed to the right places. (At least by some definitions. | |||||||
Proposal: | |||||||
Resolution: Routing is not within the scope of SOAP 1.2, but can specified using the extension mechanisms provided by SOAP 1.2. If normalization is required for content-based routing extensions to work properly, then the specifications for content-based routing extensions must ensure normalization. This appears to be feasible by defining a SOAP header block (with mustUnderstand="true") whose semantics would imply that the SOAP envelope (and its descendants) be normalized before applying a content-based routing function. In addition, a related extension feature could use a SOAP header block to indicate explicitly that a SOAP envelope has not yet been normalized; such a header block can be removed after the envelope has been normalized. To reiterate, extensions for routing and normalization are not within the scope of the SOAP 1.2 specifications. [email] | |||||||
99 | Spec | n/a | env | Design | Closed | gdaniels@macromedia.com | gdaniels@macromedia.com |
Title: detail returned from mU fault | |||||||
Description: [ email ]The SOAP spec indicates that a processor must return a MustUnderstand fault if it does not understand any headers marked mustUnderstand="1". However, it does not go into any further detail about the structure or content of the fault information, except for stating that the "detail" element may NOT be used to convey information about header-related faults. | |||||||
Proposal: The normative "Misunderstood" header in SOAP 1.2 fully resolves issue 99. | |||||||
Resolution: The XMLP WG accepted this resolution [minutes] | |||||||
100 | Spec | n/a | env | Design | Closed | gdaniels@macromedia.com | gdaniels@macromedia.com |
Title: scope of mU | |||||||
Description: There are two proposed processing models here.
In the first, the processor receives a message, decides which
pieces are for them (via the actor attribute and some magic
which lets them know out-of-band whether or not they are an
intermediary or the ultimate destination), and then applies
the rest of the SOAP semantics (mustUnderstand in particular)
to ONLY those pieces. For this model, no fault will occur if
a mustUnderstand header for some other actor arrives at the
endpoint. In the second model, an ultimate destination should
do a consistency check to make sure all extension contracts
were fulfilled before the message arrived there. If it sees a
mustUnderstand header for some other actor, it should fault.
The viewpoints on this seem to coalesce to these two:
|
|||||||
Proposal: | |||||||
Resolution: The originator proposed a rewording to address the issue which was incorporated in the specification (see Hugo's tracking on August 27th). [closure notification] | |||||||
101 | Spec | n/a | env | Design | Closed | Noah_Mendelsohn@lotus.com | |
Title: Special status of body | |||||||
Description:
SOAP Spec: 4.3.1
Relationship between SOAP Header and Body
[email]
SOAP implies that Body is just syntactic sugar for a header entry with
no actor, but there is some implication that Body is the preferred way
of carrying whichever request represents the primary function of the
message. Some clarification may be useful. For example, if multiple
headers are sent to the default actor, is there any defined processing
order relative to the body? If a header calls for "logging", for
example, can it be processed after the body itself?
See also the discussion between Doug and Hugo and its followup. |
|||||||
Proposal: See the proposed solution and its revised version. | |||||||
Resolution: Issue has been closed during the 05/12/2001 teleconference with the proposed text from Noah [email] | |||||||
102 | Spec | n/a | env | Design | Closed | Noah_Mendelsohn@lotus.com | TBTF |
Title: Clarify rules for delivering fault messages | |||||||
Description: SOAP Spec: 4.4 SOAP Fault [email] SOAP very clearly indicates situations in which a fault must be generated, but only sometimes is it clear whether and how and to whom to deliver the fault. Some of that looseness is intentional, but more clarity is needed in the explanation. (see fuller analysis in the document attached to the referenced e-mail.) | |||||||
Proposal: | |||||||
Resolution: During the W3C XMLP-WG tecon on 13-Feb-2002 the WG resolved to close issue 102 with the resolution proposed in [1], which proposed the following amendment to SOAP Part 1 Section 5.3 "Binding Framework" [2]: The third item in the number list Section 5.3 be amended as follows: <proposedText> 3. The information transmitted from node to node, and in the case of MEPs, any requirements to generate additional messages (such as responses to requests in a request/response MEP)>> and rules for the delivery or other disposition of SOAP faults generated during the operation of the MEP<<. </proposedText> We trust that this resolution now close Issue 102. [email] | |||||||
103 | Spec | n/a | env | Design | Closed | Noah_Mendelsohn@lotus.com | TBTF |
Title: Precisely describe message path semantics | |||||||
Description: SOAP Spec: 2. The SOAP Message Exchange Model [email] The SOAP specification says: "Regardless of the protocol to which SOAP is bound, messages are routed along a so-called "message path", which allows for processing at one or more intermediate nodes in addition to the ultimate destination." As discussed in the referenced e-mail, "SOAP does refer to a message path, which appears to be post facto the ordered locations and processing (there is vagueness here) that actually were visited in processing the message. There is at least an attempt to associate special behavior with the "end" of the path, where header entries with no actor are processed. The details of all this need to be stated more precisely." This is related to the suggestion that the notion of message pattern (e.g. request/response) also be clarified. This issue needs to be revisited after TBTF concludes its work | |||||||
Proposal: | |||||||
Resolution:
The introductory paragraphs of section 2 in will be rewritten as: SOAP provides a distributed processing model that assumes that a SOAP message originates at an initial SOAP sender and is sent to an ultimate SOAP receiver via zero or more SOAP intermediaries. The SOAP distributed processing model can support many message exchange patterns including but not limited to one-way messages, request/response interactions, and peer-to-peer conversations. This section defines the SOAP distributed processing model. Section 5 defines a framework for describing how message exchange patterns as well as additional features such as routing, reliability and security interact with the distributed processing model. In addition, there are some minor changes in the terminology section: 1) In the definition of "SOAP message path" replace "the ultimate SOAP receiver" with "an ultimate SOAP receiver" resulting in: "The set of SOAP senders and SOAP receivers through which a single SOAP message passes. This includes the initial SOAP sender, zero or more SOAP intermediaries, and an ultimate SOAP receiver." 2) In the definition of "SOAP intermediary" replace "towards the ultimate" with "towards an ultimate" resulting in: A SOAP intermediary is both a SOAP receiver and a SOAP sender and is target-able from within a SOAP message. It processes a defined set of SOAP header blocks in a SOAP message along a SOAP message path. It acts in order to forward the SOAP message towards an ultimate SOAP receiver. 3) In the definition of "Ultimate SOAP receiver", remove the first sentence and modify resulting in the following text: The ultimate SOAP receiver is responsible for processing the contents of the SOAP body. Normally the ultimate receiver is the last SOAP node along the SOAP message path. As described in section 2, a SOAP ultimate receiver cannot also be a SOAP intermediary. In certain circumstances, a SOAP message may not reach the ultimate recipient because of a SOAP fault generated by a SOAP node along the SOAP message path.[email] |
|||||||
104 | Spec | n/a | env | Design | Closed | Noah Mendelsohn | |
Title: Use Infoset to define messages? | |||||||
Description: SOAP Spec: 4. SOAP Envelope [email] >(this may be a bit more than a clarification) The SOAP specification currently says that "A SOAP message is an XML document that consists of a mandatory SOAP envelope...". There may be advantages to a formulation along the lines of: "Each SOAP message is defined as an XML document Infoset. Although many bindings, such as the HTTP binding provided herein, will use the serialized form of XML provided by the XML 1.0 Recommendations as augmented by the Namespaces recommendation, other bindings can adopt other serializations. In other words: this specification describes each message in the form of abstract XML Element and Attribute information items. Many protocol bindings will transmit this information in the form of the corresponding XML 1.0 documents, but other on-the-wire representations can be used by particular bindings if desired. For example, some bindings may use compressed representations." | |||||||
Proposal: See proposed resolution text accepted by the originator. | |||||||
Resolution: See resolution text: SOAP Version 1.2 Part 1 provides an Infoset definition of the SOAP Envelope. | |||||||
105 | Spec | n/a | env | Design | Closed | Noah_Mendelsohn@lotus.com | TBTF |
Title: Clarify message patterns (e.g. Request/Response) | |||||||
Description:
SOAP Spec: 2. The SOAP Message Exchange Model
[email] (this description is taken from the cited e-mail message) Although SOAP messages are fundamentally one-way, the HTTP binding serves as an example of the possibility for transport bindings to introduce higher level message patterns such as request/response. Presumably, other bindings could also support a request response model, but the SOAP specification does not mandate any particular relation between request/responses implemented by HTTP for example and SMTP (I think it should). Interestingly, the request/response model is explicitly exploited in a transport independent way by the RPC specification in chapter 7. The specification does not state, but strongly implies that RPC responses will indeed be returned to the originator of the request, and that the transport binding will be responsible for doing the necessary addressing. Certainly the HTTP binding does this. The relationship of faults to message patterns is even more subtle, and perhaps will need improvement or clarification. Specifically, section 4.4 of the SOAP specification gives information about what must be in a fault message. However, since messages are fundamentally one-way, and since there is no general-purpose notion of a request/response or other higher level pattern, nothing is stated in general as to where if at all faults are delivered. In this respect, the specification is nearly vacuous: it mandates that a fault message be constructed in certain manner, but it allows it to be dropped on the floor before anyone sees it. That's what the spec says. Reading between the lines, here's what I think it is really trying to say: "Although SOAP messages are fundamentally one-way, SOAP supports the construction of higher level message patterns on top of that. In addition to one-way, this specification includes a well architected notion of request/response, which certain applications and SOAP processors may choose to use when sending SOAP messages. SOAP transport bindings are responsible for supporting the request/response abstraction (always? optionally?). Transport bindings that support request/response are responsible for providing the ability for an intermediary or SOAP end point to return response or fault messages back to the originator of a request. Response messages can be assumed to take the exact reverse path of requests; so response and fault messages can be inspected if desired by the same actors the processed the outbound request {not sure about that..maybe we should make request/resp apply only to the endpoints?}. SOAP RPC uses the request/response message pattern, and is therefore usable only on with transport bindings that support request/response. The delivery rules for Fault messages are message pattern specific. The rules for the two message patterns supported by this version of the SOAP specification are: -
|
|||||||
Proposal: Proposition is to close this issue and focus on fault handling, which is a dupe of #102 | |||||||
Resolution: Issue 105 discusses certain ambiguities in SOAP 1.1 relating to message patterns such as request/response, one-way, etc. For example, in SOAP 1.1 it is unclear whether a non-RPC message could be sent as an HTTP response. An overalapping issue 102 questions the rules for delivering faults, and suggests that the answer may depend on message patterns. SOAP 1.2 introduces a formal notion of message pattern and clarifies its relation to bindings. The specific question of faults has not yet been considered in detail. Accordingly, the WG proposes to close issue 105 and leave issue 102 open. The WG believes that, with the exception of the fault-related questions raised in 102, issue 105 has been addressed by the latest published WD. [email, email] | |||||||
106 | Spec | n/a | env | Design | Closed | Noah_Mendelsohn@lotus.com | |
Title: Check all must understands first & process atomically? | |||||||
Description: SOAP Spec: 4.2.3 SOAP mustUnderstand Attribute SOAP Spec: 2. The SOAP Message Exchange Model [emailemail] Various readers of the SOAP specification have interpreted it to say either (1) a given actor must check that it understands all mustUnderstand headers before attempting any processing and must roll back any side effects of early MU headers if later ones fail due to application level problems or (2) that MU headers can be discovered, processed, and checked individually. Not only does this require clarification, it seems to affect the suitability of MU as the basis for certain extension features (i.e. those which must be noticed before other features are used). | |||||||
Proposal: The SOAP processing model states that a SOAP node's processing of the MU checks needs to "appear" to be done before any processing occurs [1]. This is to guarantee that no undesirable side-effects will occur as a result of noticing an unknown MU header too late. | |||||||
Resolution: The XMLP WG accepts the proposal [minutes] | |||||||
107 | Spec | n/a | env | Design | Closed | Noah Mendelsohn | Hugo Haas |
Title: Clarify the terms application, actor & related notions of identity. | |||||||
Description:
SOAP Spec: 4.2.2 SOAP actor Attribute
SOAP Spec: 2. The SOAP Message Exchange Model
[email] The SOAP specification contains statements such as "A SOAP application receiving a SOAP message MUST process that message by performing the following actions in the order listed below: ... Identify all parts of the SOAP message intended for that application (see section 4.2.2)", etc. and also "The SOAP actor global attribute can be used to indicate the recipient of a header element. The value of the SOAP actor attribute is a URI. The special URI "http://schemas.xmlsoap.org/soap/actor/next" indicates that the header element is intended for the very first SOAP application that processes the message. This is similar to the hop-by-hop scope model represented by the Connection header field in HTTP. Omitting the SOAP actor attribute indicates that the recipient is the ultimate destination of the SOAP message" SOAP thus makes clear that in certain circumstances, the same actor can have more than one URI identifier (e.g. as "next" and also something explicit). The SOAP specification should be clarified to remove all ambiguities relating to such aliases. For example, the specification should be unambiguous regarding the processing of mustUnderstand headers, generation of faults, etc. Furthermore, the specification should make clear whether users can or cannot choose to create their own aliases, and if so what processing rules apply. A special case of this issue arises at the end of the message path. It seems that this point can be addressed by at least two means, an explicit "next" and the more common absence of an actor. Can there be other user supplied names that also are acted upon by the end point? |
|||||||
Proposal:
A proposal was put forward by Eric Jenkins [email] in reference to SOAP 1.2, 9 July 2001 WD to wrap up resolution of the issue. In summary: (i) change section 4.2, 3rd encoding rule to read "The SOAP actor attribute (see section 4.2.2) and SOAP mustUnderstand attribute (see section 4.2.3) MAY be used to indicate which SOAP module will process the SOAP header block, and how it will be processed (see section 4.2.1) respectively." (ii) add the following sentence to the end of section 4.2.2 "The processing rules regarding mustUnderstand and the generation of faults apply to all headers, whether the ACTOR is implicitly or explicitly defined, and whether or not the ACTOR value is user-created." (iii) add the following sentence to the end of the last paragraph in section 2.2 "There are no restrictions on the URIs that may be used as the value of an ACTOR attribute, other than those implied by the use of the special SOAP actor named "http://www.w3.org/2001/06/soap-envelope/actor/next". (iv) add the following sentence to section 2.2 (at the end of paragraph 1 ?) "Any SOAP node, even the ultimate SOAP receiver, may be addressed by a user-created SOAP actor name." Eric asked whether there should not be a better defn of "SOAP application". He took an action to propose such a defn. The XMLP WG decided, (using numbering schema in proposal, above): (i) accepted, (ii) will be covered by editor's resolution of sections 2 and 4.2.2 overlap, (iii) as (ii), (iv)rejected |
|||||||
Resolution:
The modifications done by the Working Group in sections 2 and 4.2.2 address this issue. The crafting of a new definition of "SOAP Application" is being address in issue 139. Issue 107 has therefore been closed. [resolution text] |
|||||||
108 | Spec | n/a | env | Design | Closed | Spec Editors | |
Title: QName sufficiency for understanding | |||||||
Description: Should we specifically state that the determination of whether a SOAP node understands a block is made purely based on the entry QNAME, or should we leave it flexible. | |||||||
Proposal: | |||||||
Resolution: Issue 108 has been addressed by the following text in section 2.4 of the SOAP 1.2 spec: "It is likely that specifications for a wide variety of header functions will be developed over time, and that each SOAP node MAY include the software necessary to implement one or more such extensions. A SOAP header block is said to be understood by a SOAP node if the software at that SOAP node has been written to fully conform to and implement the semantics conveyed by the combination of local name and namespace name of the outer-most element information item of that block." [email] | |||||||
109 | Spec | n/a | bind | Design | Closed | Chris Ferris | |
Title: HTTP Extension Framework | |||||||
Description: The specification preserves the HTTP Extension Framework binding although it is an experimental specification of the IETF with no standing. I'd like to see this binding removed as I believe that it has the potential for creating interoperability problems. | |||||||
Proposal: | |||||||
Resolution: The HTTP Extension Framework section has been removed from the specification. [closure notification] | |||||||
110 | Spec | n/a | Editorial | Closed | Spec Editors | Editors | |
Title: Normative & Non-Normative sections in the spec | |||||||
Description: The specifications make little or no distinction between what is normative and what is not. A W3C specification must make this distinction. | |||||||
Proposal:
The editors' revision of the SOAP 1.2 spec provides the following in order to distinguish between what is normative and what is not: 1) All examples are explicitly marked as examples 2) Sections that are non-normative are marked as such in the section heading 3) The sections "Notational Conventions" [1][2] contains the paragraph: With the exception of examples and sections explicitly marked as "Non-Normative", all parts of this specification are normative.[email] |
|||||||
Resolution: The WG today decided to accept this proposal as resolution to issue 110 (how to distinguish normative and non-normative parts of the spec). [email] | |||||||
111 | Spec | n/a | fault | Design | Closed | Spec Editors | |
Title: Open/closed content model for fault element | |||||||
Description: The SOAP/1.1 schema defined a closed content model for
the fault element:
<complexType name="Fault" final="extension"> <element name="faultcode" type="qname" /> <element name="faultstring" type="string" /> <element name="faultactor" type="uri-reference" minOccurs="0" /> <element name="detail" type="tns:detail" minOccurs="0" /> </complexType>However the prose in section 4.4 describes it as an open content model "Other Fault subelements MAY be present, provided they are namespace-qualified". The issue is whether the content model should be open or closed. |
|||||||
Proposal: | |||||||
Resolution: [resolution] A closed model was chosen. from the specification. [closure notification] | |||||||
112 | Spec | n/a | fault | Design | Closed | RPC task force of XMLP Working Group | |
Title: Encoding faultcode | |||||||
Description: Should there be a faultcode for situations in which a receiver does not understand the encoding of a message> See for example email | |||||||
Proposal:
See the proposed resolution. |
|||||||
Resolution:
The SOAP Version 1.2 specification resolves this issue by defining a DataEncodingUnknown fault. [resolution text] |
|||||||
113 | Spec | n/a | rpc | design | Closed | Stuart Williams | RPCTF |
Title: representing void returns in presence* of parms | |||||||
Description:
This issue should be considered in conjunction with issue 16. From email, "how are void returns represented in the *presense* of [out] and/or [inout] parameters eg. for void MyProc(p1Type *p1)?" |
|||||||
Proposal: | |||||||
Resolution:
In a nut shell, the following explanation and the examples below captures the resolution. For more details, read this message. The existence of a return value is signified by the presence of a namespace-qualified accessor named 'result' with the namespace identifier "<http://www.w3.org/2001/12/soap-rpc>" and void returns are not expected to have the above named accessor.[email] |
|||||||
114 | Spec | n/a | Editorial | Closed | Yasser Shohoud | ||
Title: Specification uses xsi:null="1" instead of xsi:nil="true" | |||||||
Description: See email. Also reported by Paul Kuchenko. | |||||||
Proposal: | |||||||
Resolution: Fixed in the editors' copy. [resolution] | |||||||
115 | Spec | n/a | Editorial | Closed | Paul Kulchenko | ||
Title: Specification only allows mustUnderstand=1/0 | |||||||
Description: See email: mustUnderstand is fixed to allow '1/0/true/false' (boolean in schema), but specification explicitly says only about '1' and '0'. Also reported by Hugo Haas. | |||||||
Proposal:
Appears to be fixed in the latest editors' copy (Hugo) |
|||||||
Resolution: This has been fixed in the specification. [closure notification] | |||||||
116 | Spec | n/a | Editorial | Closed | Paul Kulchenko | ||
Title: Example 7 specifies faultcode as Name instead of QName | |||||||
Description: See email. | |||||||
Proposal: Should be env:MustUnderstand instead of MustUnderstand. See Gudge's response. | |||||||
Resolution: Fixed in the editors' copy. [resolution] | |||||||
117 | Spec | n/a | enc | Editorial | Closed | Paul Kulchenko | ETF |
Title: Clarification of the use of enc:offset and enc:position | |||||||
Description: See email: 5.1.8 says: 'A SOAP array member MAY contain a "enc:offset"' and use enc:offset and enc:position in the same context, whereas refers to [5.4.2.1 Partially Transmitted Arrays] which says about enc:offset on Array element itself. Schema shows enc:offset on Array element also. | |||||||
Proposal: See Gudge's response and Paul Kuchenko's reply. | |||||||
Resolution: The issue #117 about the need for clarification of use of attributes enc:position and enc:offset is closed because the accepted resolution to issue #144 removes these attributes. [email] | |||||||
118 | Spec | n/a | Editorial | Closed | Paul Kulchenko | ||
Title: Specification only allows root=1/0 | |||||||
Description: See email. | |||||||
Proposal:
Appears to be fixed in the latest editors' copy (Hugo) See Hugo's tracking on August 27th. Clarification still needed. |
|||||||
Resolution: This has been fixed in the specification. [closure notification] | |||||||
119 | Spec | n/a | Editorial | Closed | Paul Kulchenko | Editors | |
Title: Upgrade extension example request | |||||||
Description: See email: Appendix C says: 'The upgrade extension contains an ordered list of namespace identifiers of SOAP envelopes that the SOAP node supports in the order most to least preferred.', but doesn't give any examples on how to do it for more than one envelope supported and I can't figure it out from the text. | |||||||
Proposal: | |||||||
Resolution: Closed with the issue of the Dec 2001 Working Drafts [email] | |||||||
120 | Spec | n/a | Editorial | Closed | Paul Kulchenko | Editors | |
Title: Schema changes incomplete: change from ur-type to anyType missing | |||||||
Description: See email: D.2 Schema changes doesn't reflect changes from ut-type to anyType (anySimpleType). | |||||||
Proposal: See Gudge's response: The ur-type didn't change. All that happened was the schema-for-schemas now has a definition of the ur-type called 'anyType'. That said I should have noted in the table that the element decl and complex type named 'ur-type' had been replaced with an element decl called 'anyType'. | |||||||
Resolution: Closed with the issue of the Dec 2001 Working Drafts [email] | |||||||
121 | Spec | n/a | env | Editorial | Closed | Paul Kulchenko | |
Title: Clarification of the meaning of 'top level of serialization' | |||||||
Description: See email: There is no definition of "top level of serialization" and maybe it's a common term, but I couldn't find it and spec doesn't have any examples on multiref serialization. There should be at least one (better two, one of them should show multirefs shared between Header and Body). | |||||||
Proposal: Looks like a duplicate of issue 18. (Hugo) | |||||||
Resolution: This issue is a duplicate of issue 18. | |||||||
122 | Spec | n/a | Editorial | Closed | Fennivel | Hugo Haas | |
Title: Missing reference to augmented Backus-Naur Form (BNF) | |||||||
Description: See email: 1st. Section 1.2: "This specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2616 [5]." the reference is missing linked. | |||||||
Proposal:
The reference *does* look ok. Should go back to the author (Hugo) See Hugo's tracking on August 27th. Asked for clarification; issue will be closed if no clarification is received. |
|||||||
Resolution: No clarification has been received. The Working Group has decided on the 5 September teleconference to close the issue. [resolution] | |||||||
123 | Spec | n/a | Editorial | Closed | Fennivel | Hugo Haas | |
Title: Typo in section 1.3 | |||||||
Description: See email: 2nd. Section 1.3: the last notations should be "see section 6" instead of "see section section 6". | |||||||
Proposal:
Seems to be fixed in the editors' copy (Hugo). |
|||||||
Resolution: Fixed in the specification. [closure notification] | |||||||
124 | Spec | n/a | Editorial | Closed | David Olson | ||
Title: Error in example 31: Array containing other arrays | |||||||
Description: See email: enc:arrayType="xs:string[2]" should be enc:arrayType="xs:string[3]". | |||||||
Proposal: | |||||||
Resolution:
Addressed in the editors' copy [resolution] |
|||||||
125 | Spec | n/a | Editorial | Closed | Oliver Becker | Editors | |
Title: Meaning of "SOAP" | |||||||
Description: See email: is there intentionally no explanation of the acronym SOAP in this document? | |||||||
Proposal: | |||||||
Resolution: Closed with the issue of the Dec 2001 Working Drafts [email] | |||||||
126 | Spec | n/a | Editorial | Closed | Hugo Haas | Editors | |
Title: Use of example.org for examples in the specification | |||||||
Description: See email: It would be preferable to use www.example.org (or stockserver.example.org) instead of www.stockquoteserver.com. | |||||||
Proposal: www.stockquoteserver.com was changed. http://electrocommerce.org/abc#MyMessage is still present [email]. | |||||||
Resolution: Resolution: The drafts have been updated accordingly. | |||||||
127 | Spec | n/a | Editorial | Closed | Hugo Haas | Editors | |
Title: Avoid the use of "we" in the specification | |||||||
Description: See email: in section 2.3 and 2.4, "we" is used. | |||||||
Proposal: | |||||||
Resolution: Fixed in the editors' copy [resolution text]. | |||||||
128 | Spec | n/a | Editorial | Closed | Hugo Haas | Editors | |
Title: Use more precise language in versioning model section | |||||||
Description: See email: Since this section talks about versioning, I think that it should be clear that it talks about SOAP Version 1.2, especially because it mentions SOAP/1.1 [..]. | |||||||
Proposal: | |||||||
Resolution: Fixed in the editors' copy [resolution text]. | |||||||
129 | Spec | n/a | enc | Editorial | Closed | Hugo Haas | ETF |
Title: Section 5.1 Rules for Encoding Types in XML does not have any example | |||||||
Description: See email. | |||||||
Proposal: | |||||||
Resolution: The WG has decided to close the issue 129 because while the first subsection of the Encoding section doesn't still have any examples, it's been considerably shortened by resolutions to other issues, therefore we feel that the examples present in the following subsections are adequate and sufficient. [email] | |||||||
130 | Spec | n/a | fault | Design | Closed | Jacek Kopecky | |
Title: Extensibility of SOAP faults | |||||||
Description: See email:In SOAP, fault codes are defined to be qualified names. The specification lists four predefined codes. Then it also adds that the fault codes are extensible by separating more and less general identifiers with a dot character. I have a couple of issues with this approach to extensibility. 1) from the XML viewpoint Client and Client.Authentication are completely different identifiers. From an XML perspective it is impossible to say that "Client.Authentication" is still a "Client" fault. 2a) The specification seems to say that these extended identifiers will still be in the SOAP envelope namespace. Does this mean that anybody can arbitrarily extend the W3C SOAP envelope namespace? 2b) If the new, extended fault codes are to be in a different namespace, there is again no way to know that {some-namespace}Client.Authentication is actually also a {soap-envelope-namespace}Client fault. 3) There already is a <detail> element in the fault which might be a good place to put the detail information into. I think W3C specs should leverage what XML already provides (like qnames and hierarchical data) and minimize parsing that must be done above what XML processor does. This comment is actually also valid on the SOAP encoding array attributes. 8-) See also Paul Gibbons's email. |
|||||||
Proposal: | |||||||
Resolution: The XML Protocol Working Group has resolved Issue 130, regarding the 'dot' notation in SOAP Fault codes by removing the 'dot' notation from the specification. Thus SOAP Fault codes as defined by the specification are simply QNames. Several such faults are defined in the spec e.g. {http://www.w3.org/2001/09/soap-envelope}VersionMismatch and {http://www.w3.org/2001/09/soap-envelope}MustUnderstand. The specification may define more fault codes than it does currently before reaching recommendation. [resolution text] | |||||||
131 | Spec | n/a | bind | Design | Closed | Noah Mendelsohn | |
Title: Possible ambiguity regarding non-RPC responses in HTTP | |||||||
Description: See email:Soap 1.2 says [1] : "SOAP naturally follows the HTTP request/response message model by providing a SOAP request message in a HTTP request and SOAP response message in a HTTP response" The only formally defined notion of "Response" in the remainder of the spec is in chapter 7, and is specific to method-style RPC. So, there is a potential ambiguity as to whether the HTTP binding, as written, allows non-RPC responses to be sent as HTTP responses. This should, perhaps, be tracked as an issue. I will note that my personal preference would be to introduce a simple but somewhat more clearly architected notion of message exchange patterns, with the spec providing specific definitions for one-way and request-response, including any implications for fault handling, etc. Should that prove too ambitious, we might want to at least clarify the http binding. |
|||||||
Proposal: | |||||||
Resolution: This issue requests clarification of the notions of "response" and "request/response". The WG believes that this is resolved by the inclusion on the latest wording drafts of a formal notion of message pattern and specifically the formalization of request/response as such a pattern. [email] | |||||||
132 | Spec | n/a | Editorial | Closed | Jeff Kraus | Editors | |
Title: Typo in example 34: Schema fragment for array of phone numbers embedded in a struct | |||||||
Description: See email:It would appear that the accessor is "phoneNumbers" and not "phone-numbers" in the example introductory text. |
|||||||
Proposal: | |||||||
Resolution:
Addressed in the editors' copy [resolution] |
|||||||
133 | Spec | n/a | Design | Closed | Hugo Haas | ||
Title: SOAP and the Web architecture | |||||||
Description: See email:
The gist of the problem is that the current HTTP binding uses HTTP POST requests. However, sending an HTTP POST requests to a URI have precise semantics[4]: [..] SOAP messages carried in an HTTP POST request may have the semantics of an HTTP GET request for example, and using HTTP POST in that way can be inappropriate. Moreover, one of the Web architecture axiom is[5]: In HTTP, anything which does not have side-effects must use GET Another aspect is that doing RPC requests over HTTP POST targetted to a generic resource (say <http://example.com/genericSoapProcessor>) is also incompatible with the REST principles. Issue reported by Aaron Swartz, Mark Baker (see links from email). |
|||||||
Proposal: | |||||||
Resolution: The net of the resolution is: That the HTTP binding we offer in SOAP 1.2 Part 2 Adjuncts continue to use the HTTP POST method in the manner established in SOAP 1.1 and to note in the HTTP binding described in part 2: 1) that the HTTP binding in Part 2 Adjuncts is 'an' HTTP binding rather than 'the' HTTP binding and that our binding framework makes it is possible to define additional HTTP bindings. 2) that the HTTP binding that we define on Part 2 Adjuncts *can* be used in a manner that preserves POST semantics, but that it's up to the developer to use it that way. In addition, the WG resolved *not* to develop an HTTP binding that makes use of HTTP methods other than POST was part of its activity to deliver the SOAP 1.2 specification. | |||||||
134 | Spec | n/a | env | Design | Closed | Chris Ferris | Hugo Haas |
Title: Support of XML Base / Use of relative URIs | |||||||
Description:
[email]:We need to address any implications of XML Base on the value of the href attribute if it isn't expressed as an absolute URI. |
|||||||
Proposal:
See Noah's proposal and the discussion around it; continuation of the discussion. |
|||||||
Resolution: XML Base is fully supported by SOAP Version 1.2 [resolution text]. | |||||||
135 | Spec | n/a | env | Design | Closed | Mark Nottingham | Hugo Haas |
Title: Discarding incorrect namespaces / Envelopes without namespaces | |||||||
Description: [email]:
Section 3 states; "[A SOAP Application] MUST discard messages that have incorrect namespaces" Shouldn't this say that it MUST generate a Fault? Also, 'unsupported' seems more appropriate than 'incorrect'. Same language in 4.4.1. Finally, considering our versioning model, does it make sense to upgrade "A SOAP application SHOULD include the proper SOAP namespace on all elements and attributes defined by SOAP in messages that it generates." to MUST, and strike "... MAY process SOAP messages without SOAP namespaces as though they had the correct SOAP namespaces." This is in the context of all SOAP namespaces, not just the envelope, but it seems prudent to clarify in some fashion. |
|||||||
Proposal: This seems to have changed [email]. The Working Group needs to decide if it was/is desired. | |||||||
Resolution: The use of MUST has been ratified by the Working Group and the use of a different namespace triggers a version mismatch fault. [resolution text] | |||||||
136 | Spec | n/a | Editorial | Closed | Hugo Haas | Spec Editors | |
Title: Misc editorial comments | |||||||
Description: See email. | |||||||
Proposal: Changes made to the editors' copy by Jean-Jacques. | |||||||
Resolution: [email] | |||||||
137 | Spec | n/a | Design | Closed | Mark Jones | ||
Title: Intermediaries relaying SOAP messages without modifying them | |||||||
Description:
From email: The issue is that there are applications such as encryption and compression in which intermediaries may need to replace header or body blocks that are not targeted at the intermediary. The text as stated indicates, for example, that "relayed SOAP messages MUST contain all SOAP header blocks and the SOAP body blocks from the original SOAP message, in the original order." Some of the potential resolutions of this include: 1) keep the wording and disallow such applications. This is problematic since such applications may be essential for security and efficiency. 2) keep the spirit of the processing model. but change the change the wording to allow such "encoding transformations" as long as the abstract infoset remains the same. This seems tricky since the targeting of these blocks may need to be changed back and forth, but may be workable. 3) soften the MUST in the sentence to SHOULD, indicating that the normal state of affairs is that intermediaries will not transform the parts of the message not targeted at them, but allowing exceptional cases. 4) formally define a standard processing model as given in this paragraph, but define a mechanism to allow applications to employ alternative models. |
|||||||
Proposal: | |||||||
Resolution: Issue 137 is closed with the proposed resolution. The resolution calls out two different types of intermediary which the working group believes addresses this issue. [email] | |||||||
138 | Spec | n/a | bind | Design | Closed | MURATA Makoto | |
Title: Use of text/xml for SOAP is incorrect | |||||||
Description:
[email] See also the first discussion. |
|||||||
Proposal: See the discussion during the 17 October teleconference: not using text/xml anymore. See also the modification of the editors' copy of the spec. See a first reply to the originator. | |||||||
Resolution: While the XML Protocol WG has not yet made a decision regarding the details of the internet media type(s) which may be used to describe a SOAP message, we have agreed that text/* types should not be used. [email] | |||||||
139 | Spec | n/a | Editorial | Closed | Eric Jenkins | Chris Ferris | |
Title: Definition of SOAP Application | |||||||
Description: Resolution of issue issue 107 showed that there is no definition of SOAP application in the specification [email] | |||||||
Proposal: Chris and Eric have been instructed to come up with a definition of SOAP Application. See also a list of proposal. | |||||||
Resolution: [resolution
text] The following text was inserted in the specification
(decision taken at the 10 October teleconference):
SOAP Application A software entity that produces, consumes or otherwise acts upon SOAP messages in a manner conforming to the SOAP process model. |
|||||||
140 | Spec | n/a | env | Design | Closed | Stuart Williams | |
Title: How does a SOAP node determine if it is the anonymous actor? | |||||||
Description: [email]: There is an assumption that with respect to a given message an SOAP Node is able to determine whether it plays the role of the default/anonymous actor. For other actors there is an explicit actor URI string on which to make the determination of whether you are that actor. WRT to the default/anon actor... there is *no* discussion of the basis on which a SOAP Node determines that it plays role of default/anon actor with resect to a given received message. It seems to me at the moment that this determination is currently (in the HTTP context) based on information *outside* the message. | |||||||
Proposal:
See discussion. |
|||||||
Resolution: From the
resolution text: This issue has be resolved with the proposal
[2] to include the following text SOAP 1.2, Part 1, Section 2
(probably 2.2):
"Except for next, and none, etc. this specification does not prescribe the criteria by which a given node determines the (possible empty) set of roles in which it acts on a given message. For example, implementations can base this determination on factors including, but not limited to: hardcoded choices in the implementation, information provided by the transport binding (e.g. the URI to which the message was physically delivered), configuration information made by users during system installation, etc. " The issue about how an actor know how it is the ultimate decision is discussed in issue 146. |
|||||||
141 | Spec | n/a | env | Design | Closed | Stuart Williams | |
Title: Body block elements may be namespace qualified (should be must?) | |||||||
Description: [email]:
4.3 SOAP Body [Technical] "Each SOAP body block element information item: MAY be namespace qualified MAY have an encodingStyle attribute information item" I think that the first of these MAY's should be a MUST. 4.2 states that Header block element info items *MUST* be namespace qualified. Also, 4.3.1 describes the semantic relationship between bodies and headers which is to say that bodies are semantically equivalent to headers targetted at the default/anon actor. If that is indeed the case the need for NS qualification on bodies arises from this semantic equivalence. |
|||||||
Proposal: | |||||||
Resolution: Resolution text: "SOAP body block element information items MUST be namespace qualified." an editorial note has been added to the specasking implementors for feedback on this change. [resolution email]. | |||||||
142 | Spec | n/a | env | Design | Closed | Stuart Williams | WG |
Title: Namespace for SOAP fault codes | |||||||
Description: [email]:
4.4.1 SOAP Fault Codes: [Editorial/Technical] '..."http://www.w3.org/2001/06/soap-envelope." Use of this namespace is recommended (but not required) in the specification of methods defined outside the present specification." Two things: 1) the use of the word 'method' seems to have carried through probably from SOAP 1.0 and is tied to the notion of faults arising from method/RPC invocations. 2) I think that the RPC TF have gone against the (not required )recommentation in defining a new namespace for rpc related faults. Does this remain our recommendation? |
|||||||
Proposal: | |||||||
Resolution: he editors believe that this issue has been dealt with as the section no longer contains the word 'method' or the sentence about namespaces. [email] | |||||||
143 | Spec | n/a | Editorial | Closed | Stuart Williams | Editors | |
Title: Use of 'Client' and 'Server' in section 4.4.1 | |||||||
Description:
[email] re 4.4.1 SOAP Fault Codes. Table speaks of 'Client' faults and 'Server' faults. I think that this is the only place where the notion of 'Client' and 'Server' arise. Concepts of 'Client' and 'Server' are not developed anywhere in the document. It seems to me that 'Client' is more akin to 'Sender' and 'Server' is more akin to 'Recipient'. Regardless, I'm not sure personnally that 'Client' and 'Server' are appropriate distinctions to make in a generic SOAP messaging framework. |
|||||||
Proposal: See discussion thread. | |||||||
Resolution: Closed with the issue of the Dec 2001 Working Drafts [email] | |||||||
144 | Spec | n/a | enc | Design | Closed | Jacek Kopecky | ETF |
Title: Array information is not XML-ish | |||||||
Description: [email] The arrayType, offset and position attributes' values are hiding non-atomic data (lists of numbers, type references) in a mangled form in a string. | |||||||
Proposal: | |||||||
Resolution: The issue #144 about the form of metainformation on SOAP Encoding arrays is being closed by accepting the rewrite in [1], amended by [2] and [3]. [email | |||||||
145 | Spec | n/a | env | Editorial | Closed | Larry Masinter | Editors |
Title: XML declarations in SOAP messages | |||||||
Description: [email]: I'm not
sure that the wording is precise enough to be
unambiguous:
" A SOAP message SHOULD NOT contain processing instruction information items."I cannot tell, from this statement, whether the (recommended) XML declaration is not recommended in SOAP messages. http://www.w3.org/TR/xml-infoset/#infoitem.pi says "The XML declaration and text declarations for external parsed entities are not considered processing instructions." even though syntactically XML 1.0 defines the "<?xml version="1.0"?>" as a processing instruction. (I think the idea is that the XML declaration is just omitted from the infoset, but this is probably an issue with the XML Infoset Proposed Recommendation). |
|||||||
Proposal: Duplicate of issue 10. | |||||||
Resolution: Closed with the issue of the Dec 2001 Working Drafts [email] | |||||||
146 | Spec | n/a | env | Design | Closed | Working Group | |
Title: Does a SOAP Message Path always terminate at the default actor, anonymous actor, ultimate recipient or SOAP endpoint? | |||||||
Description: This issue originated from issue 140. See the October 10 teleconference minutes and the clarification by Stuart. | |||||||
Proposal: | |||||||
Resolution: The following text: "A SOAP Node that acts in the role of the anonymous actor with respect to a particular SOAP message becomes the ultimate recipient of that SOAP message. Such a SOAP node is responsible for processing all parts of the message intended for the anonymous actor, including the body, according to the rules described in this section. The SOAP message path for that message ends at the ultimate recipient. However, the ultimate recipient may delegate all or part of its responsibility to other entities. The ultimate recipient may happen to use distinct SOAP message exchanges to interact with such entities. Nevertheless, responsibility for the processing of parts of a SOAP message targetted at the anonymous actor rests with the ultimate recipient of that message" was inserted in the specification. [resolution text] | |||||||
147 | Spec | n/a | Editorial | Closed | Doug Davis | Editors | |
Title: How part 2 is referred to from part 1 | |||||||
Description: [email] In part 1 we talk about what's in part 2 with very specific details - by that I mean we list the current set of items in there. It seems like it would be better to just say that there's a part 2 with additional/optional things - much like we just used the term "adjunts" instead of listing all of 'em. | |||||||
Proposal: | |||||||
Resolution: Closed with the issue of the Dec 2001 Working Drafts [email] | |||||||
148 | Spec | n/a | Editorial | Closed | Doug Davis | Editors | |
Title: Too detailed introduction | |||||||
Description: [email]
The last sentence of the intro states:
These four parts are functionally orthogonal. In recognition of this, the envelope and the encoding rules are defined in different namespaces.This seems out of place since we haven't talked about the role of namespaces yet so the reader will probably not get the point of it. |
|||||||
Proposal: | |||||||
Resolution: Closed with the issue of the Dec 2001 Working Drafts [email] | |||||||
149 | Spec | n/a | Editorial | Closed | Doug Davis | Editors | |
Title: Refining the design goals text | |||||||
Description: [email] 1.1 Design goals, IMHO, need a sentence stating that while these four items listed are not part of the spec, it is not because they can not be done, but rather are just outside the scope of the spec at this time. (maybe leave off "at this time"??) | |||||||
Proposal: | |||||||
Resolution: Closed with the issue of the Dec 2001 Working Drafts [email] | |||||||
150 | Spec | n/a | Editorial | Closed | Doug Davis | Editors | |
Title: Wording in section 1.3 | |||||||
Description: [email] Section 1.3: The header block contains the parameters... We can't call them 'parameters' that implies we know how they are used and we don't - perhaps "subelements" or "xml blocks" would be better. | |||||||
Proposal: | |||||||
Resolution: Closed with the issue of the Dec 2001 Working Drafts [email] | |||||||
151 | Spec | n/a | env | Editorial | Closed | Doug Davis | Editors |
Title: Definition of SOAP Block | |||||||
Description: [email] Do we want to limit this to just SOAP blocks? By that I mean just env, header and body and their immediate children or can any xml chunk (i.e. <foo> <bar/> </foo> = 2 SOAP blocks) be called "SOAP blocks" ? The definition of "SOAP Block" isn't clear to me. | |||||||
Proposal: | |||||||
Resolution: Closed with the issue of the Dec 2001 Working Drafts [email] | |||||||
152 | Spec | n/a | env | Editorial | Closed | Doug Davis | Editors |
Title: Wording in the processing model | |||||||
Description: [email]
Section 2.1 - 2nd paragraph
A SOAP node receiving a SOAP message MUST perform processing [according to the SOAP processing model], generate SOAP faults, SOAP responses, and if appropriate send additional SOAP messages, as provided by the remainder of this specification. 1 - please add the text in [] 2 - Does it really have to be able to generate SOAP responses? What if all it does it is log the soap message - that's still a valid SOAP node. I believe the key is the processing model not whether it generates a repsonse or not. Perhaps just move the "if appropriate" so we have instead: A SOAP node receiving a SOAP message MUST perform processing according to the SOAP processing model and if appropriate generate SOAP faults, SOAP responses, and send additional SOAP messages, as provided by the remainder of this specification. |
|||||||
Proposal: | |||||||
Resolution: Closed with the issue of the Dec 2001 Working Drafts [email] | |||||||
153 | Spec | n/a | Editorial | Closed | Doug Davis | Editors | |
Title: Relationship between section 2.2. and section 4 | |||||||
Description: [email] Section 2.2 SOAP Actors and SOAP Nodes This section seems to be repeated in section 4 - do we really need both? I would be in favor of removing this section and leaving section 4. | |||||||
Proposal: See editors' proposals. | |||||||
Resolution: Closed with the issue of the Dec 2001 Working Drafts [email] | |||||||
154 | Spec | n/a | Design | Closed | Doug Davis | ||
Title: | |||||||
Description: [email]
Section 2.2 SOAP Actors and SOAP Node The roles assumed MUST be invariant during the processing of an individual SOAP message; because this specification deals only with the processing of individual SOAP messages, no statement is made regarding the possibility that a given piece of software might or might not act in varying roles when processing more than one SOAP message. "invariant" - so if during the processing of a message a SOAP node determines that it should also assume additional "roles", this would be illegal? I think this should be allowed. We've been talking about an issue very much along these lines on the mailing list but I can't remember what it's resolution was - so this might have already been resolved. |
|||||||
Proposal: | |||||||
Resolution:
Section 2.6 of SOAP Version 1.2 Part 1 now states: "This section sets out the rules by which SOAP messages are processed. Unless otherwise stated, processing must be semantically equivalent to performing the following steps separately, and in the order given. Note however that nothing in this specification should be taken to prevent the use of optimistic concurrency, roll back, or other techniques that might provide increased flexibility in processing order as long as all SOAP messages, SOAP faults and application-level side effects are equivalent to those that would be obtained by direct implementation of the following rules in the order shown below. 1. Determine the set of roles in which the node is to act. The contents of the SOAP envelope, including header blocks and the body, MAY be inspected in making such determination." ... Summarised, this resolution states that a node is explicitly allowed to inspect the message contents when deciding on the set of roles it is to play. A node is also allowed to change the set of roles it plays after starting to process blocks provided that the outcome of this is "semantically equivalent to performing the following steps separately, and in the order given".[email] |
|||||||
155 | Spec | n/a | env | Design | Closed | Doug Davis | |
Title: How to target blocks | |||||||
Description: [email]
Section 2.3 - 2nd paragraph We say that a SOAP block is targeted to a SOAP node if the SOAP actor (if present) on the block matches (see [10]) a role played by the SOAP node, or in the case of a SOAP block with no actor attribute information item (including SOAP body blocks), if the SOAP node has assumed the role of the anonymous SOAP actor. This is quite a change from 1.1 - to me this says that the "actor" attribute is the *only* way to target blocks - in 1.1 we said "The XMLP/SOAP actor global attribute can be used to indicate the XMLP/SOAP node at which a particular XMLP/SOAP header block is targeted" - notice the "can be used" - I read that to say that there may be other means of deciding which blocks are targeted for a node. Also, in section 4 (when we repeat actors and nodes!) we say "can". I think we should remove this section in favor of section 4. |
|||||||
Proposal: | |||||||
Resolution: As described in 2 SOAP Message Exchange Model, not all parts of a SOAP message may be intented for the ultimate SOAP receiver. The actor attribute information item is to be used to indicate the SOAP node at which a particular SOAP header block is targeted. See the thread on xml-dist-app@w3.org | |||||||
156 | Spec | n/a | env | Editorial | Closed | Doug Davis | Editors |
Title: What does "fail" mean? | |||||||
Description: [email]
Section 2.4 - 2nd paragraph ...local name and namespace name of the outer-most element information item of that block; or not process the SOAP message at all, and fail (see 4.4 SOAP Fault). "and fail" - shouldn't it be "and generate a fault". |
|||||||
Proposal: | |||||||
Resolution: Closed with the issue of the Dec 2001 Working Drafts [email] | |||||||
157 | Spec | n/a | Editorial | Closed | Doug Davis | Editors | |
Title: Section 2.4 wording | |||||||
Description: [email]
Section 2.4 - 1st paragraph ...increased flexibility in processing order as long as all SOAP messages, SOAP faults and application-level side effects are equivalent to those that would be obtained by direct implementation of the following rules [in order]. Please add the "in order". |
|||||||
Proposal: | |||||||
Resolution: Closed with the issue of the Dec 2001 Working Drafts [email] | |||||||
158 | Spec | n/a | env | Editorial | Closed | Doug Davis | Editors |
Title: Section 2.5 wording | |||||||
Description: [email]
Section 2.5 - bullet #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 [targeted for this node that are] identified as mandatory. Please add the "targeted for this node that are". Also, the ")" is missing from the "see 4.4 SOAP Fault". |
|||||||
Proposal: | |||||||
Resolution: Closed with the issue of the Dec 2001 Working Drafts [email] | |||||||
159 | Spec | n/a | enc | Design | Closed | Doug Davis | ETF |
Title: Wording in section 4.1.1 | |||||||
Description: [email]
Section 4.1.1 ...Each item in the list identifies a set of serialization rules that can be used to deserialize the SOAP message. The sets of rules should be listed in the order most specific to least specific. "can be used" or "MUST be used"? Also, we have lists of serialization rules, does it mean that a value on an element overrides any previously mentioned value or that it just extends the list? It sounds like it replaces it - we should be prefectly clear on this. |
|||||||
Proposal: | |||||||
Resolution: the XMLP WG has decided to close the issues #159 and #166 with the following resolution: In section 4.1.1 the paragraph before the example shall be changed to the following: "The encodingStyle attribute information item is of type anyURI in the namespace http://www.w3.org/2001/XMLSchema. Its value identifies a set of serialization rules that can be used to deserialize the SOAP message." The schema for SOAP Envelope shall be updated to reflect this. [email] | |||||||
160 | Spec | n/a | env | Design | Closed | Doug Davis | |
Title: Clarification about the omission of the SOAP actor attribute | |||||||
Description: [email]
Secton 4.3.1 While both SOAP Header and SOAP Body are defined as independent element information items, they are in fact related. The relationship between a SOAP body block and a SOAP header block is as follows: a SOAP body block is semantically equivalent to a SOAP header block targeted at the default actor and with a SOAP mustUnderstand attribute information item with a value of "true". The default actor is indicated by omitting the actor attribute information item (see 4.2.2 SOAP actor Attribute). This last sentence implies that people "should" omit the actor attribute when in fact they MUST omit it, right? I think this last sentence should be removed it could lead to some confusion. Oh wait, is the last sentence talking about headers or the body - I thought it meant the body - but now that I reread it perhaps we're talking about headers. If we're talk about headers then we should change it to something like: On headers, the default actor is indicated by... |
|||||||
Proposal: | |||||||
Resolution: Issue 160 has been addressed with the following proposal: Remove the text in question and keep section 4 primarily the infoset description of the envelope with a reference to section 2 for the specifics of how to use the "actor" attribute. [email] | |||||||
161 | Spec | n/a | enc | Design | Closed | Asir S Vedamuthu | ETF |
Title: Array Member as an Independent Element | |||||||
Description: Excerpt from the email:
Part 2, section 4.1 'Rules for Encoding Types in XML' [1], rule 8 says that each array member element is encoded as an independent element. In the previous terminology section item 11, spec says that an independent element is any element appearing at the top level of a serialization and all others are embedded elements. This is a disconnect. 'Cos, examples in section 4.4.2 'Arrays' use embedded elements to represent array members. Regardless, what is the rational for encoding array members as independent elements? |
|||||||
Proposal: | |||||||
Resolution: The issue #161 about a possible misunderstanding of the array encoding rules is closed because the XMLP WG believes the issue is not anymore an issue after the rewrite of the text in resolution to issue #144. [email] | |||||||
162 | Spec | n/a | enc | Editorial | Closed | Asir S Vedamuthu | ETF |
Title: arrayType Production Rules | |||||||
Description: [email]
Production rules [1] for arrayType value information use an unfamiliar notation, ABNF from RFC 2616. This confuses many first time readers. Because SOAP is XML based and for consistency, I suggest that we use the notation from XML 1.0. |
|||||||
Proposal: | |||||||
Resolution: The text which the issue is concerned about has been removed by the rewrite of array serialization that was accepted by the WG during the F2F meeting. [resolution text] | |||||||
163 | Spec | S21 | enc | Design | Closed | Asir S Vedamuthu | ETF |
Title: Multi-reference 'id' attribute - NOT a real ID | |||||||
Description: [email]
The conclusion here is that multi-reference representation's 'id' attribute is not a real XML 1.0 ID. This means, (a) Implementations must use additional code to simulate XML 1.0 ID (b) It fails to satisfy Usage Scenario S21 [5]. 'Cos, implementations must parse the entire document to construct an id and bearing element information item table. |
|||||||
Proposal:
1) we have agreed in resolving issue 186 that we'll explicitly define the uniqueness constraints on the attributes id and ref (so yes, in implementations there will have to be code that handles this), which makes us no longer dependent on XML Schema or DTD processing, 2) point (b) is true for our ID as well as for the "real ID" and for every possibly-forward linking mechanism, and it is therefore irrelevant to the issue of our ID not being a "real ID".[email] |
|||||||
Resolution: Summary of the resolution: in resolution to issue 186 we have agreed to add the description of constraints on the id and ref attributes which makes us independent of XML Schema or DTD processing. This does indeed mean that applications will probably get little support from existing XML processing libraries. [email] | |||||||
164 | Spec | n/a | enc | Design | Closed | Jacek Kopecky | ETF |
Title: Describing arrays with XML Schema | |||||||
Description: [email]
So I think we should add some wording to say how exactly types are described in XML Schema and what to do with schemas that don't map back to our encoding (for example complex types containing application-defined attributes.) |
|||||||
Proposal: "The WG has decided to keep the status quo as the issue is lessened by the resolution of issue 144 and the expected course of WSDL resulting thereof; and no other substantial need for in-spec specification of the mapping of SOAP Data Model schema to XML Schema has been presented." [email] | |||||||
Resolution: The issue #164 is being closed by accepting the proposal and keeping the status-quo [email] | |||||||
165 | Spec | n/a | env | Design | Closed | Noah Mendelsohn | |
Title: Deferencability of URIs | |||||||
Description: [email]
I think we need to say a bit about which such URI's are guaranteed derferenceable, and which not. We may need to say that the answer depends on features supported and/or binding. For example, I hope it's guaranteed that with SOAP+Attachements (a potential feature), references to attachements are guaranteed to resolve. On the other hand, I certainly wouldn't expect a similar guarantee for a reference to w3.org, if I'm processing the message on a Palm Pilot that is currently disconnected from the rest of the Web. The text you give is ambiguous, but could lead readers to believe that Web connectivity is required to do conforming processing of SOAP messages. |
|||||||
Proposal: | |||||||
Resolution: Issue 165 was raised by me in anticipation of our need to consider architectures such as SOAP+Attachments. The underlying concern was that many SOAP messages will processed in environments which are disconnected, in the sense that much of the web is inaccessible. In such situations, many URI's will fail to resolve. Some proposed attachement architectures, such as SOAP+Attachments and DIME, exist to provide a means of carrying information that will be guaranteed available during processing of a SOAP message. The issue suggests that we need to provide an architectural framework that will clarify the means by which attachment (or other architectures) can establish that certain URI's (presumably those referencing attachments) WILL resolve during processing of a SOAP message. The XML Protocols workgroup proposes to consider the above concerns during the development of future versions of SOAP, and specifically to consider inclusion of attachment procesing in the next revision to the workgroup's charter. Accordingly, and because our existing charter doesn't specifically call for consideration of attachments, the workgroup proposes to close issue 165 without making any changes or additions to the SOAP 1.2 working drafts. [email] | |||||||
166 | Spec | n/a | enc | Design | Closed | Asir S Vedamuthu | |
Title: Most to least specific encodingStyles, HOW? | |||||||
Description: [email]
SOAP uses encodingStyle attribute to indicate the encoding rules used for serializing parts of a SOAP message. encodingStyle attribute is a whitespace delimited list. Each item in the list is type anyURI, XML Schema built-in type. And, specification says that sets of rules should be listed in the order most specific to least specific. |
|||||||
Proposal: | |||||||
Resolution: In section 4.1.1 the paragraph before the example shall be changed to the following: "The encodingStyle attribute information item is of type anyURI in the namespace http://www.w3.org/2001/XMLSchema. Its value identifies a set of serialization rules that can be used to deserialize the SOAP message." The schema for SOAP Envelope shall be updated to reflect this. [email] | |||||||
167 | Spec | n/a | enc | Design | Closed | Asir S Vedamuthu | |
Title: Support for XML Schema Types | |||||||
Description: [email]
Part 2, section 4.1 'Rules for Encoding Types in XML' [1], rule 8 says that "SOAP arrays MUST contain a enc:arrayType attribute whose value specifies the type of the contained elements as well as the dimension(s) of the array" Plus, Part 2, section 4.1 'Rules for Encoding Types in XML' [1], rule 2 says that "MUST .. the containing element instance is itself contained within an element containing a (possibly defaulted) enc:arrayType attribute or " In brief, an array MUST contain an enc:arrayType attribute. And, this attribute specifies the type and other related information. XML Schema types can be broadly classified into two categories: named types and anonymous types. Using this example, I demonstrated that the SOAP encoding does not consider anonymous types as first class types. And, in general, not just the array, SOAP encoding does not consider anonymous types as first class types 'cos it is not possible to compute the value of xsi:type attribute either. |
|||||||
Proposal: | |||||||
Resolution: Recent work on the SOAP Data Model and SOAP Encoding sections of Part 2 of the spec has clarified the relationship between SOAP and XML Schema by taking a layered approach. Part of this clarification concerns the meanign of xsi:type in the SOAP specification. The XML Protocol Working Group considers this issue to now be closed. If you disagree please let the Working Group know as soon as possible. [email] | |||||||
168 | Spec | n/a | enc | Design | Closed | Jacek Kopecky | ETF |
Title: Type of referenced external data | |||||||
Description: [email] When using the SOAP Encoding referencing mechanism, the hrefs can point to external data. What is the type of the data? Should it depend on the MIME type of the data? What if no MIME type is available for this resource? (I don't remember anything stating that data identified by a URI must have a MIME type.) NOTE: resolution of this issue is dependent on the resolution of issue 170 | |||||||
Proposal: | |||||||
Resolution: The resolution is that we add a text into the encoding section (probably near the encoding rule #2) to this effect: "In case the receiving node cannot determine the xsi:type of a node, for example because it doesn't follow a schema during deserialization and the types are expressed in a schema, the node MAY generate a fault with the faultcode of env:Sender and the subcode of enc:UntypedValue." [email] | |||||||
169 | Spec | n/a | enc | Design | Closed | Jacek Kopecky | ETF |
Title: Forward references | |||||||
Description: [email] Some people felt forward references might be bad, other felt my original proposal disallowed forward references. I propose to keep forward references because they allow references from headers to body, which might be necessary for things like XMLDSIG, although any other referencing mechanism (most probably XML IDREF) could be used instead of SOAP Encoding referencing. | |||||||
Proposal: | |||||||
Resolution: the WG has decided to close the issue #169 by keeping the status quo - allowing forward references in the serialized form of data structures. The WG is of the opinion that this does not place an unnecessary burden on either the writers or readers of SOAP Encoded data structures. | |||||||
170 | Spec | n/a | enc | Design | Closed | Jacek Kopecky | ETF |
Title: Referencing data that can be stripped out from the message | |||||||
Description: [email] References from body to headers and references among headers may lead to situations where the referenced data is removed from the message. NOTE: resolution of issue 168 should be considered after resolution of this issue | |||||||
Proposal: | |||||||
Resolution: The XMLP Working Group has closed the issue 170 (referencing missing data) with the following text being incorporated in the spec: "When SOAP Encoding data is being deserialized and a reference to a missing ID is found, the application SHOULD generate a fault with faultcode env:Sender and subcode enc:MissingID." [email] | |||||||
171 | Spec | n/a | enc | Design | Closed | Jacek Kopecky | ETF |
Title: attribute clashes on references | |||||||
Description: [email]
For illustration of the problem:
<a foo="bar" id="1">blah</a> <b foo="baz" href="#1"/>The problem is what is the value of b? |
|||||||
Proposal: | |||||||
Resolution: The XML Protocol working group is closing issue 171 by adding the following text to part 2 of the SOAP 1.2 specification. " The serialization rules of SOAP permit the use of xsi:type attribute to represent the type of an element, and hence also the type of the corresponding graph node. The use of xsi:type to denote element types is described in XML Schema Structures [2]. Although SOAP does not mandate the use of any particular schema notation, all SOAP processors MUST recognize xsi:type references if present and MUST associate the corresponding type with the deserialized nodes. The use of xsi:type attribute on referencing accessors (I.e. those that use the href="..." construction) is subtle and it is recommended they be used with caution. Note that, per the rules of the XML Schema Specification for xsi:type, the existence of xsi:type attribute on referencing accessors does not indicate the type of the referred element, and hence does not affect the type of the corresponding node." " [email] | |||||||
172 | Spec | n/a | fault | Design | Closed | Noah Mendelsohn | |
Title: Version faults vs. client faults | |||||||
Description: Issue 135 raised a general issue relating to faults. A thread of discussion led to tentative agreement among the correspondents that we should clarify the use of version vs. client faults in the particular case that incorrect namespace qualification is used in a SOAP envelope. | |||||||
Proposal: "Once the receiver has established that the sender is sending a SOAP 1.2 envelope (by checking the namespace on the root element) then any malformation of the envelope would be a "Client" fault. This would include things like wrong element names, multiple "Header" or "Body" elements, etc." | |||||||
Resolution: "Version mismatch faults are generated only if the root element namespace doesn't match. Client faults occur if the root element namespace is known, but there is any other "malformation" of the message structure (envelope not named "envelope", body or header missing, perhaps due to bad namespaces, etc.)" [resolution text] | |||||||
173 | Spec | n/a | fault | Design | Closed | Henrik Frystyk Nielsen | |
Title: Support for multiple fault codes | |||||||
Description: How to support multiple fault codes The assumption is that we want a homogeneous mechanism for conveying multiple levels of fault codes. [email] | |||||||
Proposal: base fault code which can be understood by all SOAP 1.2 nodes and one or more fault codes that are "application specific". This is likely to make life easier for general SOAP nodes and intermediaries. [email][dist-app thread] | |||||||
Resolution: Closed with the adoption of a new schema for the structure of the env:Fault/faultcode element as described in xml-dist-app. [email] | |||||||
174 | Spec | n/a | fault | Design | Closed | Noah Mendelsohn | |
Title: simple type terminology for envelope attributes | |||||||
Description: For envelope attributes, we should use the proper XML Schemas simple type terminology, carefully indicate when we are referring to lexical vs. value space, and if a subtype is used (e.g. a boolean that only accepts lexical form "1"), make clear that we are doing so. [email] | |||||||
Proposal: | |||||||
Resolution: "attributes in the SOAP envelope described by "Part 1: Framework" are are of types from XML Schema: Datatypes (e.g. mustUnderstand is a boolean). Unless otherwise stated, all lexical forms are supported for each such attribute, and lexical forms representing the same value in the XML Schema value space are considered equivalent for purposes of SOAP processing. Thus, the boolean lexical forms "1" and "true" [ref to boolean datatype in the schema spec] are interchangeable. For brevity, text in this specification refers only to one lexical form for each value (e.g. "if the value of mustUnderstand is "true"). Unless otherwise stated, such references implicitly cover all forms corresponding to the same value in the value space. See [email] | |||||||
175 | Spec | n/a | fault | Design | Closed | Noah Mendelsohn | |
Title: contradictory text regarding removal of blocks by intermediaries | |||||||
Description: Section 2.6 of the latest editors' draft retains the text: "If the SOAP node is a SOAP intermediary, the SOAP message pattern and results of processing (e.g. no fault generated) MAY require that the SOAP message be sent further along the SOAP message path. Such relayed SOAP messages MUST contain all SOAP header blocks and the SOAP body from the original SOAP message, in the original order, except that SOAP header blocks targeted at the SOAP intermediary MUST be removed (such SOAP blocks are removed regardless of whether they were processed or ignored)." This is known to conflict with the ability to implement encrypting or compressing intermediaries; such intermediaries will presumably remove blocks NOT targeted to that intermediary, and do other seemingly prohibited manipulations. [email] | |||||||
Proposal: | |||||||
Resolution: Closed as duplicate of issue 137 [email] | |||||||
176 | Spec | n/a | encoding | Design | Closed | Noah Mendelsohn | |
Title: Canonicalization/rewrite of headers | |||||||
Description: had assumed that a SOAP intermediary relaying an unprocessed header would preserve its contents character-for-character, probably including whitespace, but certainly preserving the exact form of attribute values, namespace prefices, etc. Henrik made the case that many SOAP processors will parse a message into abstract form, with the result that relayed headers may for example change: mustUnderstand="1" to mustUnderstand="true" Essentially, the question is how much of XML canonicalization may be done by an intermediary relaying a header [email] | |||||||
Proposal: | |||||||
Resolution:
The text outlined in [this message] was adopted as the resolution text to the issue with proposed modifications by yourself and taking into account the accepted resolution to issue 137. It should be noted that the mail proposed resolution went through considerable discussion and was discussed at the Feb 2002 WG f2f (to be posted). At the f2f, the WG instructed the editors to exercise some amount of editorial discretion in order to avoid duplication or requirements and description of the SOAP message construct in general.[email] |
|||||||
177 | Spec | n/a | encoding | Design | Closed | Jacek Kopecky | |
Title: missing elements same as nils? | |||||||
Description: In SOAP Encoding in structures and in arrays, accessors can be omitted. The current WD says: (section 4.2, rule #9) "A NULL value or a default value MAY be represented by omission of the accessor element. A NULL value MAY also be indicated by an accessor element containing the attribute xsi:nil with value '1 or true' [...]" (section 4.5) "An omitted accessor element implies either a default value or that no value is known. The specifics depend on the accessor, method, and its context." This text applies to both arrays and structs. Wwhat does an omitted accessor really mean? [email] | |||||||
Proposal: | |||||||
Resolution: the issue 177 was closed with the resolution proposed in this message. The resolution is, in short, to simplify rule #8 in section 3.1 to only speak about NULL values, and to remove (or downgrade) section 3.6 which talks about default values. [email] | |||||||
178 | Spec | n/a | meta | Design | Closed | Raj Nair | |
Title: requirements imposed by end-to-end features | |||||||
Description: Text is needed to clarify the requirements on binding imposed by end-to-end features. An example is an end-to-end security association that an intermediate node is not able to participate in. [email] | |||||||
Proposal: (1) Noah proposed that we make it the responsibility of the next hop on the path of a message to ensure that the hop after it can support the feature; (2) Glen proposed that we specify text that limits the scope of the binding contract to each hop. (3) Raj had originally proposed text that requires an intermediary to generate a fault if it is not able to accept a SOAP message without violating existing end-to-end conditions of the message. | |||||||
Resolution:
We delete the last sentence of the last paragraph in part 1, section 5.1 and add an explanatory note. The result is: "The combination of the SOAP extensibility model and the SOAP binding framework provides some flexibility in the way that particular features can be expressed: they can be expressed entirely within the SOAP envelope (as blocks), outside the envelope (typically in a manner that is specific to the underlying protocol), or as a combination of such expressions. Note: Certain features may require end-to-end as opposed to hop-to-hop processing semantics. While the 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. 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). It is recommended that, where practical, end-to-end features be expressed as SOAP header blocks, so that SOAP's processing rules can be employed."[email] |
|||||||
179 | Spec | n/a | meta | Design | Closed | Marc Hadley | |
Title: One-way messaging in SOAP 1.2 | |||||||
Description: In Part 1, section 5.3 we find: "Every binding specification MUST support the transmission and processing of one-way messages as described in this specification. A binding specification MAY state that it supports additional features, in which case the binding specification MUST provide for maintaining state, performing processing, and transmitting information in a manner consistent with the specification for those features." This paragraph is potentially confusing, either we mean: (i) All bindings must support a one-way MEP, in which case there are two issues: (a) we currently don't define a one way MEP in the specification (b) the HTTP binding we do define doesn't support a one-way MEP or (my reading) (ii) All bindings must at a minimum define how to move a message from one node to another, in which case I would propose that we add a clarification along the lines of "Note, this does not mean that all bindings must support a one way MEP, only that they MUST define how to move a message from one SOAP node to another". [email] | |||||||
Proposal: | |||||||
Resolution: during the 25th-26th February face to face meeting, the XML Protocol WG has decided to close issue 179 [1] following the proposed text in this message with the exception that "MUST support" was changed to "MUST enable". [email] | |||||||
180 | Spec | n/a | RPC | Design | Closed | Martin Gudgin | |
Title: Parameter ordering in Section 4.1 | |||||||
Description: In the editors copy of Part 2[1], section 4.1[2] states of [in] and [in/out] parameters in the request that; 'These appear in the same order as in the procedure or method signature.' For [out] and [in/out] parameters in the response it states; 'The return value accessor SHOULD be first, followed by the accessors for the parameters which SHOULD be in the same order as they appear in the procedure or method signature.' Why the inconsistency? I think we should say the same thing for both request and response. I don't have a *strong* opinion about whether we should enforce order or not, but I'd tend to lean toward lining up the response description with the description of the request. [email] | |||||||
Proposal: | |||||||
Resolution: The XMLP WG has resolved to close issue 180 with this proposal. Briefly, this proposal states that RPC requests and responses can map parameters into struct or array accessors that provide access to parameter values by name or by position respectively. [email] | |||||||
181 | Spec | n/a | Fault | Design | Closed | Jean-Jacques Moreau | |
Title: Incostitency between section 4.4.3 and section 2 | |||||||
Description: I think this whole discussion is pointing out an inconsistency between section 4.4.3 "SOAP faultactor Element" and section 2 (with or without the ed's proposed rewrite). Specifically, section 2 introduces the notion of roles, which nodes play. IMO, this section places a greater emphasis on roles than on nodes. In contrast, section 4.4.3 is mute about roles (see quote below), which I find quite disturbing since a node is allowed to play multiple roles. I would be tempted to say that the faultactor attribute really ought to identify not just the node that faulted (coarse-grained), but the exact role in which that node operated (fine-grained). "faultactor [...] is intended to provide information about which SOAP node on the SOAP message path caused the fault to happen [...]. It is similar to [...] SOAP actor [...] but instead of indicating the target of a SOAP header block, it indicates the source of the fault. The value of [...] faultactor [...] identifies the source of the fault. [email] | |||||||
Proposal: | |||||||
Resolution: Issue 181[1] is closed with this resolution text. Essentially the fault element now allows both faultactor and faultrole elements to be provided. [email] | |||||||
182 | Spec | n/a | Fault | Design | Closed | Marc Hadley | |
Title: Fault Code restriction | |||||||
Description: Part 1, Section 2.6 contains the following paragraph: "If processing is unsuccessful, exactly one fault MUST be generated by the node. Header-related faults other than mustUnderstand faults (see 4.4 SOAP Fault) MUST be SOAP Sender or DataEncodingUnknown faults (see 4.4.5 SOAP Fault Codes) and MUST conform to the specification for the corresponding SOAP header block. Faults relating to the body MUST be SOAP Sender or DataEncodingUnknown faults (see 4.4.5 SOAP Fault Codes)." The restrictions on the type of faults that may be generated seems strange. E.g. why couldn't header processing lead to a Receiver fault (out of memory etc...). [email] | |||||||
Proposal: "If processing is unsuccessful, exactly one fault MUST be generated by the node. Header-related faults other than mustUnderstand faults MUST conform to the specification for the corresponding SOAP header block." | |||||||
Resolution:
During the W3C XMLP WG Telcon on 6th March 2002 the WG agreed to close Issue 182 by making the amendment to Part 1 section 2.6 proposed by Marc with final wording as amended by Stuart/Henrik in email and on the call to: "Failure is indicated by the generation of a fault. SOAP message processing MAY result in the generation of at-most one fault. Header-related faults other than mustUnderstand faults MUST conform to the specification for the corresponding SOAP header block."[email] |
|||||||
183 | Spec | n/a | env | Design | Closed | Henrik Frystyk Nielsen | |
Title: Default values of SOAP header block attributes | |||||||
Description: Section 4 defines the semantics of omitting both the actor/role attribute and the mustUnderstand attribute: 1) Section 4.2.2 says: "Omitting the SOAP actor attribute information item implicitly targets the SOAP header block at the ultimate SOAP receiver. An empty value for this attribute is equivalent to omitting the attribute completely, i.e. targeting the block at the ultimate SOAP recipient." 2) Section 4.2.3 says: "Omitting this attribute information item is defined as being semantically equivalent to including it with a value of "false"." However, neither of the statements above provides any guidance as whether the attributes should lexically appear in the SOAP message when they have their default values. Later in the section, we find the following statement: 3) Section 4.2.1 says: "SOAP header block attribute information items MUST appear in the SOAP message itself in order to be effective; default values which may be specified in an XML Schema or other description language do not affect SOAP processing (see 3.1 XML Schema)." While it might seem that these statements are contradictory, the intention of the 3) is not to disallow omitting the SOAP header block attributes but to state that SOAP modules can not default their values. For example, a SOAP security module can not set the default mU value to true in the schema definition for the header blocks that it defines. Currently, the vast majority (if not all?) of existing SOAP implementations do not generate SOAP header block attributes with their default values. In addition, 4) Section 3.1 says: "A SOAP message MUST NOT impose any XML schema processing (assessment and validation) requirement on the part of any receiving SOAP node. Therefore, SOAP REQUIRES that all attribute information items, whether specified in this specification or whether they belong to a foreign namespace be caried in the serialized SOAP envelope." Section 3.1 seems to go too far in the requirement of not requiring schema processing. The only piece that we can possible talk about is that schema processing MUST NOT be required in order to correctly process a SOAP message according to the SOAP processing model in section 2. I don't think we have anything to say about whether application-defined data relies on schema processing or not. [email] | |||||||
Proposal: Whenever we have a choice in what can be generated by a sender and what must be accepted by a receiver, it seems useful to invoke the general Robustness Principle "Be liberal in what you accept, and conservative in what you send". The proposal consists of three main parts and a minor part: A) Clarify the paragraph in section 4.2.1 to remove the apparent contradiction. B) Add a sentence to the two paragraphs mentioned the semantics of omitted SOAP header block attributes that indicated the guidelines for handling default attribute values. C) Clarify section 3.1 to say that it only applies to SOAP processing as defined by section 2. D) In addition, I would suggest that we add a paragraph in the introduction of part 1 (for example as part of section 3 explicitly calling out the Robustness Principle as a general principle for SOAP processors. [email] | |||||||
Resolution: During the W3C XMLP WG Telcon on 6th March 2002 the WG agreed to close Issue 183 by making the amendments proposed by Henrik and amended by Noah. [email] | |||||||
184 | Spec | n/a | enc | Design | Closed | Asir S Vedamuthu | |
Title: XML Legacy Types in SOAP Encoding Schema | |||||||
Description:
SOAP Encoding schema declares several elements whose type is a complex type derived from XML legacy types: (a) <xs:element name="NMTOKEN" type="tns:NMTOKEN" /> (b) <xs:element name="NMTOKENS" type="tns:NMTOKENS" /> (c) <xs:element name="ID" type="tns:ID" /> (d) <xs:element name="IDREF" type="tns:IDREF" /> (e) <xs:element name="ENTITY" type="tns:ENTITY" /> (f) <xs:element name="IDREFS" type="tns:IDREFS" /> (g) <xs:element name="ENTITIES" type="tns:ENTITIES" /> (h) <xs:attribute name="NOTATION" type="tns:NOTATION" /> (an attribute decl) Per XML 1.0, all these types are attribute types. XML Schema specifies that [3], for compatibility these types should be used only on attributes. But, SOAP specs do not specify any such health warning. |
|||||||
Proposal: [Resolution 1] Remove these element declarations and related complex types from the SOAP Encoding schema. 'Cos, I do not see any uses cases for representing any part of the SOAP Data Model using these element decls or complex types. OR [Resolution 2] Include the health warning in XML Schema by reference | |||||||
Resolution:
Issue 184 is closed with the following resolution; 1. The NOTATION type will be removed from the encoding schema 2. A health warning will be added to the encoding schema and Part 2 of the specification stating that the XML 1.0 types should be avoided as they are only intended for use in attribute values.[email] |
|||||||
185 | Spec | n/a | enc | Design | Closed | Jacek Kopecky | |
Title: SOAP Encoding multistructs | |||||||
Description:
This is an issue that was brought up a few times but never really discussed. In SOAP Encoding (and the Data Model) we have the notion of a compound type which contains some members. The members may be accessed via their names or ordinal position or both. We have three or four ways of accessing the members: A) 1) by name, 2) by position, 3) by both; B) 1) by name, 2) by position, 3) by name and then by position, 4) by position and then by name. I assume B is the case because IMO there are enough differences between B3 and B4 to make them distinct and I claim that B3 together with B4 cover all the useful cases of A3 and that there is no overlap between them. The "useless" cases of A3 not covered by B3 and B4 are the cases where the application changes its approach significantly and arbitrarily while processing a single multistruct. In B1, the order of members in the XML serialization is completely insignificant, the names carry information. In B2, the names of members in the XML serialization are completely insignificant, the order carries information. In B3, the relative order of two elements with the same name is significant, while the relative order of two elements with different names is disregarded; the names are significant. In B4, the order of all the elements is significant, so are all the names. Let's see an example of a serialized multistruct: <multistruct> <a>1</a> <b>2</b> <a>3</a> <c>4</c> <a>5</a> </multistruct> The difference between B3 and B4 is in the order of choosing by the position and by the name if a service wants a member with the name 'a' and position 2. B3: choose all 'a's, then choose the second one. Result: <a>3</a>. B4: choose the second member (<b>2</b>) and ensure it's an 'a'. (Actually, a more real scenario would be to get the second member, choose the action based on its name, then process the value.) My opinion is that in B3, the multistruct would be better described as a structure containing array of 'a's, array of 'b's and an array of 'c's. In B4, the natural mapping of the data (on the data-model level) would be to an array of tuples {name, value}. Both remappings would mean complicating the XML serialization but the data would be so much more clear about their meaning. (Ultimately this is the same for representation of sparse arrays and partially transmitted arrays and references to attachments or other stuff, since we removed the incomplete arrays and hrefs.) Asir's given me the argument that with the current syntax (same for B3 and B4) the receiver can choose to approach the data differently from how the sender approaches them. But this is hairy because if the sender has data modeled as B3, it will view my first example and the following one as equal and may choose a random one, whereas a B4 receiver will see them as different and will possibly treat them differently with different results - how's that for interoperability? It's like if an application was free to treat a struct like an array - same ordering issues. The second example: <multistruct> <a>1</a> <a>3</a> <a>5</a> <b>2</b> <c>4</c> </multistruct> |
|||||||
Proposal: I) remove multistructs completely (keeping structs and arrays whose combinations can be used to model any B3 and B4 multistructs and arguably any A3 multistructs) and only allow accessing members either by name or by position, not both, II) distinguish between B3 and B4 multistructs just like we distinguish between structs and arrays, for example by mandating that B3 multistructs have type descended from enc:Multistruct, and B4 multistructs have type descended from enc:DocumentOrderStruct. | |||||||
Resolution: This issue was closed with Last Call issue 297, see email | |||||||
186 | Spec | n/a | enc | Design | Closed | Martin Gudgin | |
Title: Uniqueness and reference constraints of id and ref | |||||||
Description:
At the recent face-to-face it came to light that more prose was needed around the id and ref attributes in the SOAP Encoding section of Part 2 Specifically the uniqueness constraint needs to be made explicit. We cannot refer to XML Schema for this, because the uniqueness constraint is defined in XML Schema Part 1 as part of a validation episode and SOAP requires that no such episodes be mandated.Note that this issue is linked to issue 163 [email] |
|||||||
Proposal:
Add the following text to Section 3 of Part 2
Constraints on id and ref attribute information items The value of a ref attribute information item MUST also be the value of exactly one id attribute information item |
|||||||
Resolution:
3.1.4.3 Constraints on id and ref attribute information items The value of a ref attribute information item MUST also be the value of exactly one id attribute information item. A ref attribute information item and an id attribute information item MUST NOT appear on the same element information item.[email] |
|||||||
187 | Spec | n/a | proc | Design | Closed | Stuart Williams | |
Title: Handling badly formed SOAP Messages | |||||||
Description:
During the F2F I was actioned to raise an Issue with respect to the first Ednote in SOAP 1.2 Part 2 section 7.4.1.2.1, part of the HTTP binding. The ednote states: <quote> As described this model tends to hide a malformed message from the local SOAP Node and handle the malformation in the binding - basically because it would not be possible to instantiate the CurrentMessage to pass up for processing. An alternate formulation might be to allow CurrentMessage to carry badly formed messages and let the SOAP processor/node deal with it. As presented here we can have define the bindings behaviour with respect to particular failures. </quote> The issue that the ednote raises is two fold: 1) From a descriptive point of view where do we place the responsibility to describe behaviour associated with the receipt of poorly formed SOAP messages? Malformations might include: XML that is not-well formed; Unsupported envelope version; some unsupported message encapsulation (eg MIME/DIME etc). 2) From a more practical point-of-view, is it right that a binding implementation 'hide' the receipt of such 'broken' messages from the SOAP processor/node. This may be more moot, because it probably makes inappropriate assumptions about the structure of an implementation.[email] |
|||||||
Proposal: | |||||||
Resolution:
At the XML Protocol WG meeting of Mar 27, the WG decided to resolve
Issue 187 "Handling badly formed SOAP Messages" by adopting the
solution in [1] and as amended by the following addition editorial item:
"the editors should check that the binding framework says that binding specification writers should ensure that bindings can handle all failures that may be anticipated within the binding."[email] |
|||||||
188 | Spec | n/a | enc | Design | Closed | Noah Mendelsohn | |
Title: When should xml declarations appear in examples? | |||||||
Description: SOAP messages are XML Infosets. Examples in the specification sometimes have an XML declaration. Should such declarations be ommitted? | |||||||
Proposal: The attribute found in the XML declaration, namely version, encoding and standalone are modelled in the infoset as the [version], [character encoding scheme] and [standalone] properties of the Document Information Item. Having XML declarations in examples is thus completely coherent. | |||||||
Resolution:
The attributes found in the XML declaration, namely version, encoding and standalone are modelled in the infoset as the [version], [character encoding scheme] and [standalone] properties of the Document Information Item. Having XML declarations in examples is thus completely coherent. I would also note that the latest editor's copy[2] makes explicit reference to the infoset properties listed above.[email] |
|||||||
189 | Spec | n/a | enc | Design | Closed | Noah Mendelsohn | |
Title: What version number of XML should SOAP 1.2 specify? | |||||||
Description: Does putting <?xml version='1.0' ?> in our examples imply that the SOAP 1.2 spec is tied to XML 1.0 and cannot be used with a future version. | |||||||
Proposal: The attribute found in the XML declaration, namely version, encoding and standalone are modelled in the infoset as the [version], [character encoding scheme] and [standalone] properties of the Document Information Item. Having XML declarations in examples is thus completely coherent. | |||||||
Resolution:
Enchance the description of the Envelope encoding to include discussion stating that the values of the [version], [character encoding scheme] and [standalone] infoset properties are unimportant as far as SOAP is concerned.[email] |
|||||||
190 | Spec | n/a | meta | Design | Closed | Noah Mendelsohn | |
Title: How can we keep applications from supplying defaults for their own purposes? | |||||||
Description:
We can't keep applications from requiring validation for their own content. How can we keep applications from supplying defaults for their own purposes? We even do it for our own attributes." <quote> Therefore, SOAP REQUIRES that all attribute information items, whether specified in this specification or whether they belong to a foreign namespace be caried in the serialized SOAP envelope. </quote>[email] |
|||||||
Proposal: Except where this specification mandates a default value for an attribute, SOAP messages must carry explicit values for all attribute information items required by this recommendation. | |||||||
Resolution: The XMLP WG has decided to close issue #190 with the resolution at [1]. Specifically, the WG feels this issue has already been addressed by the resolution of issue #183 [2]. [email] | |||||||
191 | Spec | n/a | meta | Design | Closed | Noah Mendelsohn | |
Title: Reception of SOAP message with a DTD? | |||||||
Description:
The original is incoherent. A message with a DTD is not a SOAP message. Legal bindings don?t even accept infosets that contain DTDs for transmission. How could one be received?" <quote where="soap12-part1.html#soapenv"> On receipt of a SOAP message containing a Document Type Declaration, a SOAP receiver MUST generate a fault (see 4.4 SOAP Fault) with a fault code of "DTDNotSupported". </quote>[email] |
|||||||
Proposal: SOAP nodes MUST NOT transmit, and transport bindings MUST NOT provide for transmission of SOAP messages with Internal Subset DTDs. | |||||||
Resolution:
Issue 191 [1] was opened by me as a request to clarify the treatment of
DTDs by SOAP and by SOAP protocol bindings. A comprehensive analysis and
proposal for a solution was presented by me at [2]. Minor refinements
were proposed by Henrik Frystyk Nielsen [3]
This note is to formally announce that the workgroup has decided to close issue 191 in the manner proposed by me, as amended by Henrik. [email] |
|||||||
192 | Spec | n/a | meta | Design | Closed | Mark Baker | |
Title: When is a Fault a Fault? | |||||||
Description:
I went over the binding framework and the HTTP binding and noticed a problem; no where is it stated how SOAP processors should recognize faults. The issue is that sometimes a SOAP node may want to send a message that includes a Fault, but is not intended to be processed as a Fault. An example would be if a SOAP node is asked, perhaps via a debugging interface, to return the last fault it sent. Using HTTP as an example, the HTTP response code is used as the authoritative determinant of the intent; if it's a 2xx response, then the Fault is not processed as a Fault. If it's a 4xx or 5xx, then it is.[email] |
|||||||
Proposal:
1) update the binding framework to state that each binding should declare that the authoritative determinant of whether a message is a fault or not should be the underlying protocol 2) update the default HTTP binding to state that a SOAP Fault MUST only be processed as a SOAP Fault if the response code is 4xx or 5xx. |
|||||||
Resolution:
The WG has reviewed and accepted the proposed resolution described in [2] with the following amendment to part 1) of the proposal which the editors have been instructed to incorporate: "Senders must not send messages that has a Fault element in the body and also additional elements. If a receiver receives such a message, the implications are undefined."[email, email] |
|||||||
193 | Spec | n/a | edit | Editorial | Closed | Jean-Jacques Moreau | |
Title: Missing reference from section "2.6 Processing SOAP Messages" to section "2.7 Relaying SOAP Messages" | |||||||
Description:
<quote where="Section 2.6 Processing SOAP Messages, bullet 5"> In the case of a SOAP intermediary, and where the message is to be forwarded further along the message path, remove all SOAP header blocks targeted at the node, and possibly insert new SOAP header blocks. </quote> |
|||||||
Proposal:
originalAuthor="Noah" amendedBy="Jean-Jacques" In the case of a SOAP intermediary, and where the SOAP message exchange pattern and results of processing (e.g. no fault generated) require that the SOAP message be sent further along the SOAP message path, relay the message as described in Section 2.7 Relaying SOAP Messages. |
|||||||
Resolution:
In the case of a SOAP intermediary, and where the SOAP message exchange pattern and results of processing (e.g. no fault generated) require that the SOAP message be sent further along the SOAP message path, relay the message as described in section 2.7 Relaying SOAP Messages.email |
|||||||
194 | Spec | n/a | enc | Design | Closed | Simon Fell | |
Title: encodingStyle on soap:Header/soap:Body | |||||||
Description:
I don't beleive that the schema as it stands allows for the encodingStyle attribute to appear on the Envelope or Header elements, whilst the prose allow for that situation, however my understanding of XSD is shakey enough that i could be wrong. Shouldn't the Envelope and Header complex types include an attributeGroup reference to the encodingStyle attribute group ? Also is there any reason why encodingStyle uses an attribute group ?[email, from original comment] |
|||||||
Proposal: | |||||||
Resolution:
The encoding style attribute MUST NOT appear in ANY element defined in the envelope namespace[email] |
|||||||
195 | Spec | n/a | enc | Design | Closed | Tim Ewald | |
Title: mandating local name and namespace name of EII representing result outbound edge a bad idea | |||||||
Description:
I want to raise an issue with the model for RPC invocations and responses defined in Section 5, Using SOAP for RPC, of SOAP 1.2 Part 2. Specifically, mandating the "result" element from the "http://www.w3.org/2001/12/soap-rpc" namespace as the accessor for an RPC call's return value is problematic because that element is defined as being of anyType.(Comment: The commentator would prefer that we just mandate the local name, leaving the namespace name and type properties to be defined by some higher layer) [email] |
|||||||
Proposal: Mandate that the local name be 'result' but that the namespace name may be determined by means not specified in SOAP 1.2 | |||||||
Resolution:
The XMLP WG has decided to close issue #195 with the resolution at [1]. Essentially, QNames are used to identify the result. Please let us know immediately if you disagree with this resolution.[email] |
|||||||
196 | Spec | n/a | enc | Design | Closed | Jean-Jacques Moreau | TBTF |
Title: HTTP binding/status code | |||||||
Description: I would like to raise the following issue: two tables[1,2] in the HTTP binding contain the strings "??" and "???". The meaning of these characters is ambiguous: it could either mean "any status code is valid", or "we haven't though about this problem yet; work in progress". Also, it is not clear whether only a certain subset of the HTTP status code is acceptable, instead of all possible HTTP status code. | |||||||
Proposal: | |||||||
Resolution:
As a result of the discussion, I think the table will look like this: env:VersionMismatch 500 [see a] env:MustUnderstand 500 [see b] env:Sender 400 [see c] env:Receiver 500 [see d] [a] Similar to HTTP/1.1's 505 "HTTP Version Not Supported" [b] Similar to HTTP/1.1's 501 "Not Implemented" [c] Similar to HTTP/1.1's 400 "Bad Request" [d] Similar to HTTP/1.1's 500 "Internal Server Error" [e] Because the sender sends something that the receiver can't accept[email] |
|||||||
197 | Spec | n/a | enc | Design | Closed | Yves Lafon | TBTF |
Title: Negotiation of features in HTTP Binding | |||||||
Description: In 7.1, it says :HTTP applications MUST use the media type "application/soap+xml" according to [12] when including SOAP 1.2 messages in HTTP exchanges. However, this does not apply if attachments are sent along with the document. Also, what is the best way to negotiate the content-type? Trial and error? doing an idempotent (ie: GET) to get the server capabilities? Only in the description of the service? | |||||||
Proposal: | |||||||
Resolution:
"Conforming implementations of this binding: 1. MUST be capable of sending and receiving messages serialised using media type application/soap+xml whose proper use and parameters are described in [12]. 2. MAY send requests and responses using other media types providing that such media types provide for at least the transfer of SOAP XML Infoset. 3. MAY, when sending requests, provide an HTTP Accept header. This header: (i) SHOULD indicate an ability to accept at minimum application/soap+xml (ii) MAY additionally indicate willingness to accept other media types that satisfy 2 above." [...][email, email] |
|||||||
198 | Spec | n/a | edi | Editorial | Closed | Paul Prescod | |
Title: Split part 2 | |||||||
Description:
There are three major usage modes or ways to think about SOAP. 1. as a very generic messaging framework, as described in part one of the specification. 2. as a remote procedure call mechanism as in Part 2, Section 5. 2 a) An encoding for parameter values 2 b) A method calling syntax 3. as an extension mechanism for HTTP, as discussed in 6 [... (cut, see email for full details) ...] I propose, therefore that SOAP be split, as XSL was split, into languages with unique names. I propose SOAP-Messaging, SOAP-RPC and the SOAP HTTP Binding. Arguably SOAP-RPC could also be split into the SOAP encoding and SOAP-RPC but it may not be helpful to slice that finely[email] After the first resolution sent by the WG, Paul replied with this: No, it is not an acceptable resolution but I did not expect an acceptable resolution. I am just trying to be a good citizen in trying to influence the specifications rather than merely criticize them. You've referred me to an internal URI which I unfortunately cannot access. Nevertheless, let me reiterate that there is widespread confusion about what SOAP is. I think that this is in large part because under the one name there are very different technologies. The last specification I can remember that bundled so many diverse, seemingly independent pieces under one name was HyTime. Be afraid. Be very afraid. [...][email] |
|||||||
Proposal: | |||||||
Resolution:
The WG has already split the original SOAP 1.1 specification into
two parts (Part 1 and Part 2). The WG considers that this is
sufficient for now, and does not want to split the specification
any further (although the WG reserves the right to split the
specification further in the future if it so desires).
[email].
On 27 March 2002, the WG considered Paul Prescod's response to this WG's stated resolution, and the WG decided to stay with its resolution |
|||||||
199 | Spec | n/a | enc | Spec | Closed | Noah Mendelsohn | |
Title: allow xml:lang on faultString? | |||||||
Description: * Section 5.4.2: Should we allow xml:lang on faultString? This will probably be a concern for the internationalization folks. [email] | |||||||
Proposal:
1. Add the following to the top of the envelope schema[1]; <xs:import namespace='http://www.w3.org/XML/1998/namespace' /> 2. Add a type definition as follows; <xs:complexType name='faultstring' > <xs:simpleContent> <xsd:extension base='xs:string' > <xs:attribute ref='xml:lang' /> </xs:extension> </xs:simpleContent> </xs:complexType> 3. Amend the Fault type as follows; <xs:complexType name="Fault" final="extension" > <xs:annotation> <xs:documentation> Fault reporting structure </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="faultcode" type="tns:faultcode" /> <xs:element name="faultstring" type="tns:faultstring" /> <xs:element name="faultactor" type="xs:anyURI" minOccurs="0" /> <xs:element name="faultrole" type="xs:anyURI" minOccurs="0" /> <xs:element name="detail" type="tns:detail" minOccurs="0" /> </xs:sequence> </xs:complexType> 4. Amend the description of faultstring as follows; The faultstring element information item has: A [local name] of faultstring . A [namespace name] which has no value. An optional attribute information item with a local name of lang and namespace name of http://www.w3.org/XML/1998/namespace ( see [ref to http://www.w3.org/TR/REC-xml.html#sec-lang-tag] )[email] |
|||||||
Resolution: The WG has reviewed and accepted the proposed resolution. [email] | |||||||
200 | Spec | n/a | bind | Spec | Closed | Chris Ferris | |
Title: SOAPAction header and "action" parameter on media type | |||||||
Description:
IIRC, we agreed to place the "action" parameter on the
application/soap+xml media type. Section 7.5 of the latest version of
part 2 of the specification doesn't talk about this at all, it only
talks about the use of the SOAPAction header.
We should talk about whether we want to support two mechanisms for specifying "action" or not. If we want or need to support both, we should define what happens if they're both used at the same time. We also need to specify how the RequiredSOAPActionURI property interacts with the action parameter in this case. [email] |
|||||||
Proposal:
1) I would say that we should only have it in one place and like the direction of moving it entirely into the media type definition as a parameter. 2) This is the trickiest part - one of the important reasons for having a known content type is to indicate that *this* is a SOAP message. If two parties are not using a known content type then that information clearly is not there anymore. I can think of two ways to go: 2.A) We leave it entirely up to the media type being used to indicate in some manner that this is a SOAP message. 2.B) We maintain the SOAPAction in some manner (for example in an appendix) that allows is to be used with content types other than "application/soap+xml" indicating that this is a SOAP message. 3) The spec editors should add a note to the spec that we know that this is an ID with no standing. 4) This was carefully put together as the resolution [6] of issue 95 [5]. While some of the details regarding the status codes used will be changed slightly as a result of it being a media-type parameter, and that its value can't be relative, the overall resolution still stands.[email] |
|||||||
Resolution:
The WG has reviewed and accepted the proposed resolution described in [1] with the "2.A" option and not "2.B".[email] |
|||||||
201 | Spec | n/a | meta | Spec | Closed | Noah Mendelsohn | |
Title: Inconsistency in the spec regarding structure of the body | |||||||
Description:
"An ultimate SOAP receiver MUST correctly process the immediate children of the SOAP body (see 5.3 SOAP Body). However, Part 1 of this specification (this document) mandates no particular structure or interpretation of these elements, and provides no standard means for specifying the processing to be done." We introduced this formulation during the great debate over body interpretation. In the non-fault case, I think I am happy with it. I think it also implies that ascribing semantics to a body containing a fault is optional (or, conversely, you might view the first and second sentences as contradictory in this respect.) In the case of faults, first of all, it contradicts the rest of the specification in claiming that we mandate no structure for the body. I suspect we should open an issue at least on that. My guess is that (with apologies in advance to Mark Baker) many of us had assumed that we wanted to mandate not just the structure, but also the interpretation in the case that a fault was received. Maybe the issue should be expanded to include that question as well, though knowing Mark's views, it may not be easy to achieve quick consensus on a resolution.[email] |
|||||||
Proposal: | |||||||
Resolution:
"An ultimate SOAP receiver MUST correctly process the immediate children of the SOAP body (see 5.3 SOAP Body). However, with the exception of SOAP faults (see ....), part 1 of this specification (this document) mandates no particular structure or interpretation of these elements and provides no standard means for specifying the processing to be done."[email] |
|||||||
202 | Spec | n/a | meta | Design | Closed | Herve Ruellan | |
Title: Definition of intermediaries | |||||||
Description:
The current definition of SOAP Intermediaries in section 2.7.1 [1] takes into account only the case where the forwarding of the message is requested by one (or more) SOAP blocks or by the MEP. I think that some SOAP nodes may decide to forward a SOAP message using other criteria. Nevertheless, I think that those nodes MUST act in the role of a SOAP intermediary. I think in particular that that might be the case for active intermediaries.[email] |
|||||||
Proposal:
I think that a small change in section 2.7.1 would suffice to solve this problem by making clear that any SOAP node forwarding a message must act in the role of a SOAP intermediary. <original> The semantics of one or more SOAP blocks in a SOAP message, or the SOAP message exchange pattern used MAY request that the SOAP message be forwarded to another SOAP node on behalf of the initiator of the inbound SOAP message. In this case, the processing SOAP node acts in the role of a SOAP intermediary. </original> <proposal> When a SOAP node forwards a SOAP message received from another SOAP node, it MUST acts in the role of a SOAP intermediary. Such forwarding may be requested by the semantics of one or more SOAP blocks in the SOAP message, by the SOAP message exchange pattern used or by any other means. </proposal> |
|||||||
Resolution:
During the 24th April telcon, the XML Protocol Working Group has decided to close issue 202 [1] with the resolution proposed in [2].[email] |
|||||||
203 | Spec | n/a | meta | Design | Closed | Glen Daniels | |
Title: SOAP module specification | |||||||
Description:
Many moons ago, Paul Denning, David Clay, and myself took an action to start writing up a "module template" to essentially describe the framework for writing a SOAP 1.2 extension. For various reasons, this work fell by the wayside, but I note that we haven't come back to it or replaced it with anything else. I think it's critical that we have some section somewhere offering some guidance as to how to do this, since this is ostensibly going to be one of the major extensibility mechanisms by which a lot of people build on the platform we are creating. At a minimum, I would think such a section would indicate that a SOAP extension spec/module: * MUST identify itself with a URI (this becomes really critical when trying to describe services with something like WSDL, or when doing negotiation with an unknown party) * MUST clearly specify the content and semantics of the header blocks used to implement the behavior in question * MUST clearly specify any known interactions with other extensions in terms of semantics or sequence (for instance "this encryption extension will encrypt the contents of the body. On the receiving end, it MUST run before other extensions which rely on the unencrypted contents of the body.") * MAY indicate that the extension functions as an implementation of a SOAP feature as defined in sec 3 of part 1. In this case, the spec must also clearly specify the relationships (if appropriate) between any abstract properties defined in the feature spec (as described in sec 5 of part 2) and concrete instantiations in the SOAP envelope * SHOULD have a well-defined name of EITHER "SOAP extension" OR "module" :)[email] |
|||||||
Proposal: | |||||||
Resolution:
3.2 SOAP Modules A SOAP module is a feature which is expressed as SOAP headers. A module specification follows the following rules. It: * MUST identify itself with a URI. This enables the module to be unambiguously referenced in description languages or during negotiation. * MUST clearly and completely specify the content and semantics of the header blocks used to implement the behavior in question, including if appropriate any modifications to the SOAP Processing model. * MAY utilize the property conventions defined in section 5 of part 2 in describing the functionality that the module provides. If these conventions are followed, the module specification MUST clearly describe the relationship between the abstract properties and their representations in the SOAP envelope. Note that it is possible to write a feature specification purely in terms of abstract properties, and then write a separate module specification which implements that feature, mapping the properties defined in the feature spec to SOAP header blocks in the module. * 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 body and inserts a header containing a checksum and an indication of the encryption mechanism used. The spec for such a module would indicate that the decryption algortihm on the receiving side must run *prior* to any other modules which rely on the contents of the body.[email] |
|||||||
204 | Spec | n/a | binding | Design | Closed | Mark Nottingham | |
Title: HTTP transcoding | |||||||
Description:
Has the WG considered whether to give advice about/dictate handling of the 'no-transform' cache-control directive, as well as the '214 Transformation applied' warning-value in the HTTP binding? It may be prudent to do so.[email] |
|||||||
Proposal: | |||||||
Resolution:
In [1] you ask whether the WG has considered the various cache-control directives and in particular "no-transform" and how that applies to SOAP. The WG discussed the issue and came to the following conclusion: Any HTTP implementation should certainly take advantage of the features provided by HTTP. However, there is nothing particularly special about how the various cache-control directives apply to SOAP - they are defined in an entirely orthogonal manner and so the WG didn't see a reason for why the binding should say.[email] |
|||||||
205 | Ext:MT | n/a | binding | Design | Closed | Christopher Ferris | |
Title: Media type (application/soap+xml) | |||||||
Description:
2) It isn't clear that we should not adopt the fragment identifier meaning associated with application/xml. I don't think that we want to preclude use of fragment identifiers. 7. Fragment identifiers No meaning is associated with fragment identifiers for content described by the "application/soap+xml" media type. 3) Base URI is not addressed and should be IMO (it is in RFC3023). From section 6 of [SOAP12P1]: SOAP does not define a base URI but relies on the mechanisms defined in XML Base[11] and RFC 2396[6] for establishing a base URI against which relative URIs can be made absolute. Suggest that a section entitled "Base URI" be added to the ID and suitable text (possibly directly from the spec, or maybe just referencing where in the spec this is defined) be added. (Added during TBTF teleconf of 15 Apr 2002: Check also encoding supported (UTF-8, etc...) [email] |
|||||||
Proposal: | |||||||
Resolution:
1. with regard Fragment-Identifiers in the text of the SOAP 1.2 specification, include a reference to RFC-3023 2. with regards XML-Base in the text of the SOAP 1.2 specification, state that SOAP 1.2 uses XML Base and include a reference to the W3C XML Base Recommendation[email] |
|||||||
374 | spec | n/a | meta | Design | Closed | Marc Hadley | |
Title: Comment on Attachment Feature WD - CID support | |||||||
Description:
On the editorial front I would like to recommend redressing the balance between MIME and DIME by adding a reference to the SOAP with Attachments note[1] rather than just MIME itself. I would also recommend that the bibliography entries for WS-Attachments, WS-Security and SOAP with Attachments be moved to a new section; "Non-normative References" in line with approach taken for parts 1 and 2 of the spec. On the technical front I wonder whether the spec should require/specify support for at least the CID[3] referencing scheme, rather than punting this completely to the packaging spec specification. This wouldn't preclude a packaging spec introducing additional referencing schemes but would provide at least a minimum of functionality common to all packaging specs.[email] |
|||||||
Proposal: | |||||||
Resolution:
This issue is now covered by issues 376, 377 and 378[email] |
|||||||
375 | spec | n/a | meta | Design | Closed | Christopher Ferris | |
Title: Comments on Attachment Feature WD - Compound Structure, part,... | |||||||
Description:
"Compound SOAP structure A compound SOAP structure consists of a primary SOAP message part and zero or more related secondary parts." I'm a little concerned that the term 'part' used in this spec will be confused with the term 'part' as used in WSDL. It isn't clear to me that a 'part' in WSDL would equate to a 'part' as described in this spec. The term 'part' as used in this context equates to MIME or DIME message 'part', which is certainly one way to look at this, but IMO, not the only way to view it. I'm also a little concerned with the use of the term 'compound SOAP structure'. The serialization of a SOAP message that contains references external to the SOAP envelope may be as a compound structure, but that again is just one way of achieving the objective of making the referents available to the receiving node(s). I look at the serialization of a SOAP message and its referents using MIME or DIME as an optimization that should be (nearly) invisible to both the sending and receiving application, not as its inherent structure. "4. Compound SOAP Structure Model A compound SOAP structure consists of a primary SOAP message part and zero or more related secondary parts that are distinct from the primary SOAP message but related to it in some manner. Secondary parts can be used to contain data that naturally represents a resource in its own right or which is cumbersome to represent within the primary SOAP message part. The latter can be due to the size, type, or format of the data--a secondary part may be an audio clip, an image, or a very large view of a database, for example." Again, I look at the problem a little differently. A SOAP message may contain references to resources that are external to the SOAP envelope itself. The references themselves define the semantics of the relationship between the SOAP message and the referent resource. It is outside the scope of this specification to attribute specific semantic relationship between the SOAP message and its constituent parts (SOAP header blocks and the contents of the SOAP body) and the resources to which these may refer. "It is important to note that the compound SOAP structure model does not modify or supersede the message envelope concept defined by SOAP. Nor does it define a processing model for any of the parts of a compound SOAP structure including the primary SOAP message part. The processing model for the primary SOAP message part is defined by SOAP. The application-defined semantics of the SOAP message provides the processing context for the secondary part(s)." Actually, I believe that there *is* a processing model and that this specification SHOULD articulate that processing in the abstract (not in terms of specific bindings to a particular technology such as MIME or DIME). To an extent, this is discussed in section 6, but it is not characterized in the manner that I believe it should be. I believe that the processing model should be as follows: - a sending SOAP node implementing this feature must serialize the referents of any references in accordance with the chosen "packaging" technology. - a receiving SOAP node implementing this feature must provide necessary functionality that enables any resources referenced within the SOAP message to be resolved (dereferenced, whatever term of art is chosen to mean make the bytes of the representation(s) of the identified resource is made available to the application). I believe that that is the essence of this feature in a nutshell. "The compound SOAP structure model does not require that a SOAP receiver process, dereference, or otherwise verify any secondary parts of a compound SOAP structure. It is up to the SOAP receiver to determine, based on the processing context provided by the primary SOAP message part, which operations must be performed (if any) on the secondary part(s)." This paragraph troubles me deeply. I think that I understand the motivation behind the text, but I think it misses the point, at least from my perspective. See the second bullet above regarding what I perceive are the receiving SOAP node's responsibilities. I think that we need to be careful in the language that we choose. From SOAP1.2 part 1: "SOAP node The embodiment of the processing logic necessary to transmit, receive, process and/or relay a SOAP message, according to the set of conventions defined by this recommendation. A SOAP node is responsible for enforcing the rules that govern the exchange of SOAP messages (see 2. SOAP Processing Model). It accesses the services provided by the underlying protocols through one or more SOAP bindings." I think that we need to be very careful about articulating the responsibilities of a SOAP node with respect to any features that are defined. According to the definition above, a SOAP node's responsibilities include 'processing' which I believe we now mean to include the application-level processing. From SOAP 1.2 part 1 section 2.6: "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." I believe that what the wording: "The compound SOAP structure model does not require that a SOAP receiver process, dereference, or otherwise..." is intended to mean that, just as the SOAP spec says nothing about what a receiving SOAP node does with the contents of a SOAP header block or the SOAP body, this feature imposes no requirement that the representations of the resources actually *be* processed, dereferenced or otherwise validated, etc. However, it DOES have a responsibility to provide for the means by which the references can be resolved in the event that the application-level processing determines that a particular reference be resolved. Bottom line for me is that we should define this feature in terms of SOAP, not in terms of the anticipated technology that might implement the feature.[email] |
|||||||
Proposal: | |||||||
Resolution:
This issue is now covered by issues 379, 380, 381 and 382[email] |
|||||||
376 | spec | n/a | meta | Design | Closed | Marc Hadley | |
Title: Comment on Attachment Feature WD - Add a ref to SOAP Attachment Note | |||||||
Description:
[This is the first part of closed issue 374:] On the editorial front I would like to recommend redressing the balance between MIME and DIME by adding a reference to the SOAP with Attachments note[1] rather than just MIME itself.[email] |
|||||||
Proposal: | |||||||
Resolution:
During the 11 September 2002 telcon, the WG has decided to close issue 376, "Add a ref to SOAP Attachment Note" with the following resolution: A reference to the "SOAP Messages with Attachments" note will be added to the AF spec.[email] |
|||||||
377 | spec | n/a | meta | Design | Closed | Marc Hadley | |
Title: Comment on Attachment Feature WD - move bib refs | |||||||
Description:
[This is the second part of closed issue 374:] I would also recommend that the bibliography entries for WS-Attachments, WS-Security and SOAP with Attachments be moved to a new section; "Non-normative References" in line with approach taken for parts 1 and 2 of the spec.[email] |
|||||||
Proposal: | |||||||
Resolution:
During the 11 September 2002 telcon, the WG has decided to close issue 377, "move bib refs" with the following resolution: The reference section will be split in two subpart, the first one being normative, and the second one being informative. The second subpart will contain the references to WS-Security, WS-Attachments, SOAP with Attachments.[email] |
|||||||
378 | spec | n/a | meta | Design | Closed | Marc Hadley | |
Title: Comment on Attachment Feature WD - CID support | |||||||
Description:
[This is the last part of closed issue 374:] On the technical front I wonder whether the spec should require/specify support for at least the CID[3] referencing scheme, rather than punting this completely to the packaging spec specification. This wouldn't preclude a packaging spec introducing additional referencing schemes but would provide at least a minimum of functionality common to all packaging specs.[email] |
|||||||
Proposal: | |||||||
Resolution:
During the 11 September 2002 telcon, the WG has decided to close issue 378, "CID support" with the following resolution: The AF spec will no require/specify support for the CID referencing scheme. Rationale: It is up to each particular binding (implementing AF) to chose which URI scheme(s) to use. One of the reason is that the 'natural' URI scheme to use will depend on the means used to move the attachments. However, the WG also decided to add some clarification that a secondary part can have multiple URIs, that a binding can use one or more URI schemes and that both absolute and relative URIs can be used.[email] |
|||||||
379 | spec | n/a | meta | Design | Closed | Christopher Ferris | |
Title: Comments on Attachment Feature WD - Concern over the term "part" | |||||||
Description:
[1st part of closed issue 375:] "Compound SOAP structure A compound SOAP structure consists of a primary SOAP message part and zero or more related secondary parts." I'm a little concerned that the term 'part' used in this spec will be confused with the term 'part' as used in WSDL. It isn't clear to me that a 'part' in WSDL would equate to a 'part' as described in this spec. The term 'part' as used in this context equates to MIME or DIME message 'part', which is certainly one way to look at this, but IMO, not the only way to view it.[email] |
|||||||
Proposal: | |||||||
Resolution:
During the 11 September 2002 telcon, the WG has decided to close issue 379, 'Concern over the term "part"' with the following resolution: A note will be added in section 3. Terminology to clarify that the use of the term 'part' is independent of its use in other specifications.[email] |
|||||||
380 | spec | n/a | meta | Design | Closed | Christopher Ferris | |
Title: Comments on Attachment Feature WD - Concern over the term "Compound Structure" | |||||||
Description:
[2nd part of closed issue 375:] "Compound SOAP structure I'm also a little concerned with the use of the term 'compound SOAP structure'. The serialization of a SOAP message that contains references external to the SOAP envelope may be as a compound structure, but that again is just one way of achieving the objective of making the referents available to the receiving node(s). I look at the serialization of a SOAP message and its referents using MIME or DIME as an optimization that should be (nearly) invisible to both the sending and receiving application, not as its inherent structure.[email] |
|||||||
Proposal: | |||||||
Resolution:
During the 11 September 2002 telcon, the WG has decided to close issue 380, 'Concern over the term "Compound Structure"' with the following resolution: The paragraph in section 6. Implementation starting with "Note: The compound SOAP structure model...", will be changed from a note to more normative prose by removing the term 'Note' at the beginning of the paragraph.[email] |
|||||||
381 | spec | n/a | meta | Design | Closed | Christopher Ferris | |
Title: Comments on Attachment Feature WD - specifying relationships between primary and secondary parts" | |||||||
Description:
[3rd part of closed issue 375:] "4. Compound SOAP Structure Model A compound SOAP structure consists of a primary SOAP message part and zero or more related secondary parts that are distinct from the primary SOAP message but related to it in some manner. Secondary parts can be used to contain data that naturally represents a resource in its own right or which is cumbersome to represent within the primary SOAP message part. The latter can be due to the size, type, or format of the data--a secondary part may be an audio clip, an image, or a very large view of a database, for example." Again, I look at the problem a little differently. A SOAP message may contain references to resources that are external to the SOAP envelope itself. The references themselves define the semantics of the relationship between the SOAP message and the referent resource. It is outside the scope of this specification to attribute specific semantic relationship between the SOAP message and its constituent parts (SOAP header blocks and the contents of the SOAP body) and the resources to which these may refer.[email] |
|||||||
Proposal: | |||||||
Resolution:
During the 11 September 2002 telcon, the WG has decided to close issue 381, 'specifying relationships between primary and secondary parts' with the following resolution: The paragraph from section 4. Compound SOAP Structure Model starting with "Secondary parts can be used to contain data..." is not intended as normative prose but rather as an example. To make this explicit, the words 'For exmample,' will be added at the beginning of this paragraph.[email] |
|||||||
382 | spec | n/a | meta | Design | Closed | Christopher Ferris | |
Title: Comments on Attachment Feature WD - Clarification of SOAP nodes'responsibilities | |||||||
Description:
[4th part of closed issue 375] "The compound SOAP structure model does not require that a SOAP receiver process, dereference, or otherwise verify any secondary parts of a compound SOAP structure. It is up to the SOAP receiver to determine, based on the processing context provided by the primary SOAP message part, which operations must be performed (if any) on the secondary part(s)." This paragraph troubles me deeply. I think that I understand the motivation behind the text, but I think it misses the point, at least from my perspective. See the second bullet above regarding what I perceive are the receiving SOAP node's responsibilities. I think that we need to be careful in the language that we choose. From SOAP1.2 part 1: "SOAP node The embodiment of the processing logic necessary to transmit, receive, process and/or relay a SOAP message, according to the set of conventions defined by this recommendation. A SOAP node is responsible for enforcing the rules that govern the exchange of SOAP messages (see 2. SOAP Processing Model). It accesses the services provided by the underlying protocols through one or more SOAP bindings." I think that we need to be very careful about articulating the responsibilities of a SOAP node with respect to any features that are defined. According to the definition above, a SOAP node's responsibilities include 'processing' which I believe we now mean to include the application-level processing. From SOAP 1.2 part 1 section 2.6: "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." I believe that what the wording: "The compound SOAP structure model does not require that a SOAP receiver process, dereference, or otherwise..." is intended to mean that, just as the SOAP spec says nothing about what a receiving SOAP node does with the contents of a SOAP header block or the SOAP body, this feature imposes no requirement that the representations of the resources actually *be* processed, dereferenced or otherwise validated, etc. However, it DOES have a responsibility to provide for the means by which the references can be resolved in the event that the application-level processing determines that a particular reference be resolved.[email] |
|||||||
Proposal: | |||||||
Resolution:
During the 11 September 2002 telcon, the WG has decided to close issue 382, 'Clarification of SOAP nodes'responsibilities' with the following resolution: The WG thinks the AF specification about SOAP nodes' responsibilities is clear enough. Therefore no action will be undertaken.[email] |
|||||||
429 | paswa | n/a | meta | Design | Closed | Jacek Kopecky | |
Title: | |||||||
Description:
there are two questions we identified on the PASWA proposal: 1) does the application see xbinc:Include? 2) does the SOAP processing model see xbinc:Include? Everyone seems to agree that the application should not see xbinc:Include. The second question can be re-framed as whether we want smart protocol bindings or whether bindings can be ignorant of xbinc:Include. The PASWA proposal is designed to be able to work with bindings ignorant of it, using the DoInclude header. On the other hand there is much appeal in creating smart protocol bindings that would hide xbinc:Include processing completely. So the issue is: do we allow protocol bindings to optimize transmission of SOAP Envelope infoset using the xbinc:Include technique? Even further, do we require that bindings take care of xbinc:Include and that the SOAP Processing model never sees an infoset with xbinc:Include element information items?[email] |
|||||||
Proposal:
We should allow xbinc:Include element to reach the SOAP Processing model and specify (if the proposal isn't clear enough already) how DoInclude header works and how the processing model doesn't change (e.g. it doesn't have to be re-run). We should also explicitly say that protocol bindings may be built which use xbinc:Include themselves, in which case the SOAP processor doesn't ever see xbinc:Include elements (or the DoInclude header). |
|||||||
Resolution:
We have resolved that our interest in xbInc:Include, as proposed in [2] is at most for use in bindings. It should not in general be visible to applications, and if present is in general to be interpreted by bindings prior to application of the SOAP processing model.[email] |
|||||||
431 | paswa | n/a | meta | Design | Closed | Marc Hadley | |
Title: semantics of attachments wrt intermediaries | |||||||
Description:
1: "What are the semantics of attachments w.r.t. SOAP intermediaries. E.g. do we expect intermediaries to preserve what is serialized as attachments and what is serialized inside the SOAP envelope."[email] |
|||||||
Proposal: | |||||||
Resolution:
Marc, you raised an issue (logged as #431, see http://www.w3.org/2000/xp/Group/xmlp-issues#x431) regarding the semantics of attachments with regard intermediaries. The XMLP WG yesterday agreed to close the issue using the text in http://lists.w3.org/Archives/Public/xml-dist-app/2003Aug/0025.html.[email] |
|||||||
432 | paswa | n/a | meta | Design | Closed | Marc Hadley | |
Title: which nodes to serialize | |||||||
Description:
2: "How does the binding determine which nodes to serialize as attachments ?"[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP WG has closed this issue by stating that data to be optimized MUST be in the canonical form of base64 as defined by XML Schema. So a binding is free to optimize any nodes that have such a lexical form.[email] |
|||||||
435 | mtom | n/a | meta | Design | Closed | Martin Gudgin | |
Title: how does a receiver determine which elements were optimized | |||||||
Description:
-- derived from 432 -- Another question that came up is how does a receiver determine which elements were optimized which led to discussion of a receiver side property 'OptimizedElements'. This may be worth recording as a separate issue.[email] |
|||||||
Proposal: | |||||||
Resolution:
During the 22 Oct 2003 teleconference, the XMLP WG has decided to close this issue with the following resolution: "SOAP receiver cannot determine which elements were optimized"[email] |
|||||||
436 | mtom/paswa | n/a | meta | Design | Closed | Martin Gudgin | |
Title: should we say anything about the responsibility of intermediaries? | |||||||
Description:
-- derived from 431 -- are intermediaries required to preserve optimization/non-optimization of element content? -- should we say anything about the responsibility of intermediaries?[email] |
|||||||
Proposal: [see also email and following thread] | |||||||
Resolution:
The WG has decided that this issue is now closed, having been adequately addressed by the closure text for Issue 431 at http://lists.w3.org/Archives/Public/xml-dist-app/2003Aug/0025.html and which now exists in sections 2.4.3 and 2.4.4 of the SOAP MTOM Editors Copy at http://www.w3.org/2000/xp/Group/3/06/Attachments/OptimizationMechanism.html.email |
|||||||
437 | mtom/paswa | n/a | meta | Design | Closed | Noah Mendelsohn | |
Title: How to establish base URI? | |||||||
Description:
MTOM/PASWA can be used to carry encapsulated documents in SOAP. Such encapsulated documents may contain relative URIs. The workgroup must determine the rules for establishing base URIs for resolving such relative references (and if there are any other uses of base URIs, for them too.) Among other things, we need to decide whether the requirements are different for content carried as children of a Representation element [1] vs. for other Paswa content (Note that other Paswa content is not in general distinguishable by inspection of the SOAP infoset.)[email] |
|||||||
Proposal: | |||||||
Resolution:
During the 29 Oct 2003 teleconference, the XMLP WG has decided to close this issue by adopting Jacek's proposal [1] inlined here: <<< For the general case of optimized pieces of data we should note that if the optimized data contains a relative URI, the base URI is the same as if the data wasn't optimized. In particular if we decide to identify optimized parts using some kind of URIs, these URIs don't affect the base URI of relative URIs in the optimized data. For the Representation (header) element (or whatever equivalent we come up with) we should say that it does in fact establish a base URI for relative URIs contained in the actual representation and that the base URI is the URI used by the Representation element to identify the resource whose representation it carries. >>>[email] |
|||||||
438 | mtom | n/a | meta | Design | Closed | Mark Nottingham | |
Title: Optimizations other than Base64 | |||||||
Description:
1. Should MTOM accommodate encodings/optimizations other than base64? a. If so, should the list be open-ended (i.e., extensible)?[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP WG has decided to close issue 438 by declining at the moment to include other types than base64 because no other types are necessary for the fulfillment of our usecases and requirements.[email] |
|||||||
439 | n/a | meta | Design | Closed | Amy Lewis | ||
Title: regex for media types | |||||||
Description:
> Given that the type rule is extensible by IANA, it seems most sensible > > to NOT enumerate the current types. This leaves us with: > > [a-zA-Z0-9!#$%^&\*_-\+{}\|'.`~]+/[a-zA-Z0-9!#$%^&\*_-\+{}\|'.`~]+ Unless the working group/task force has reason to believe that the IANA is going to change its long-standing policy of conservatism in the approval of new types, this statement is not quite correct. One new type has been added since the publication of the four MIME RFCs ("model"). There is good reason to suggest that an enumeration of types is preferable to an open content model: what are you going to do with a type you don't recognize? The reluctance of IANA to approve new types is another factor, as is the reasoning behind it: new types are avoided because they require changes to deployed software. So, I would think that it would be better to enumerate, with an escape to vendor-defined or random types. But the enumeration is valuable, signalling the set of types that processors should (in some fashion) support.[email] |
|||||||
Proposal: | |||||||
Resolution:
Amy, The Working Group has conferred and believes that these issues have already been considered.[email] DISSENT: email |
|||||||
440 | n/a | meta | Design | Closed | Noah Mendelsohn | ||
Title: Sharing MTOM parts for identical leaf nodes | |||||||
Description:
It occurs to me that in certain use cases the identical large binary might logically serve as content to multiple leaf nodes. This could in principle be done by reference to headers, but that changes the vocabularies and is not in all cases natural. I wonder whether we should allow a smart MTOM implementation to point multiple xbinc:Includes to the same mime part (I.e. use the same URI)? Seems like a win to me, and I can quite easily imagine implementations that would know from the construction of the DOM or similar structure that the content was identical. In any case, I think we should open an issue to make clear what the rule is, even if we just clarify that you must not link a given mtom part from more than (or perhaps less than?) a single xbinc:Include. My current leaning would be to allow flexibility in both directions. Multiple xbinc:Includes should be able to ref the same content, and it should be possible to carry content that is not referenced at all (e.g. to avoid the need for reference counting, or to maintain certain kinds of signatures, even if a header with a reference is removed.) That said, I wouldn't expect many implementations to avail themselves of the permission to send large useless content, but I think the sharing makes sense.[email] |
|||||||
Proposal:
See also:[email, discussion, discussion] |
|||||||
Resolution:
The XMLP WG has resolved this issue as follows: XOP will allow unreferenced MIME parts MTOM and HTTP binding will allow unreferenced MIME parts but such MIME parts play no part in SOAP processing. XOP will allow multiple refs per binary part MTOM will allow multiple refs per binary part HTTP binding will allow only one ref per binary part[email] Not for objection but for the record: Noah's email |
|||||||
441 | mtom | n/a | meta | Design | Closed | Noah Mendelsohn | |
Title: Canonical forms in MTOM | |||||||
Description:
On today's call [Wed Oct 1], we adopted a proposal that says: " there is no property explicitly suggesting what to optimize. The rule is that a binding MAY optimize any, all or none of the items that are of dm:type xsd:base64binary. We agree to discuss later whether data to be optimized must be in canonical form, and if so what canonical." [...] So, we need to discuss whether to indicate that only canonical forms can be optimized by MTOM. If yes, we need to decide whether to adopt the canical form suggested in the errata to XML schema or some other form.[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP WG has closed this issue by stating that data to be optimized MUST be in the canonical form of base64 as defined by XML Schema.[email] |
|||||||
442 | mtom | n/a | meta | Design | Closed | Martin Gudgin | |
Title: Representation header | |||||||
Description:
I took an action item to write up a strawman proposal for metadata and the Representation header. Here it is: 1. For each MIME header create an attribute information item in the [attributes] of the Representation element information item 2. Set the [local name] of the AII to the name of the MIME header 3. Set the [namespace name] of the AII to http://www.w3.org/2003/11/soap/metadata (actual URI TBD). 4. Set the [normalized value] of the attribute is the value of the MIME header. Note that this is just a strawman to start discussion. My own take is that this approach is actually the reverse of what we actually want. I suggest that we actually start by deciding what metadata we care about in two cases: a. On a Representation element information item b. On an arbitrary element information item whose content is in canonical base64 and then define a mapping from that metadata to the appropriate MIME headers.[email] |
|||||||
Proposal: [email (Yves), email (Jacek)] | |||||||
Resolution:
the WG has decided to close issue 442 by accepting my proposal [2] with the friendly amendment stating that the Representation header can be used multiple times in one message if multiple representations are to be carried with that message. We expect to open an issue on providing an extension to this header that will enable full HTTP caching behavior of recipients. We also expect to open an issue on clarifying how the Representation header should play with the SOAP processing model, specifically with respect to roles and mustUnderstand. Providing media type information for the data in the Representation header is still an open issue - 443. |
|||||||
443 | mtom | n/a | meta | Design | Closed | Jacek Kopecky | |
Title: Media-typing binary data in XML | |||||||
Description:
By media-typing I mean providing the media type as defined by RFC 2045 and 2046. In July, I proposed [1] a new section to be added to our document, that would cover PASWA [2] sections 3, 7 and appendix I. I basically copied the appropriate text from PASWA. Mark Nottingham reacted [3] to that by presenting a few different options for providing media types to binary data in XML. On a related topic, Philippe le Hegaret summarized a few different approaches [4] for the WS-Description WG. Subsequently, the WS-Description WG has agreed to do some work in this area. Media-typing binary data in XML is going to be useful (IMO necessary) for the Representation header work we're about to start. As the actual media-typing specification work has moved to the WS-Desc WG, I suggest that we collect the requirements we have on the media-typing spec. Below is a first-cut list of requirements that I gathered from what I think Representation header will need: 1. It must be possible to indicate unambiguously the media type of a piece of binary data that's present as base64-encoded character content of an element information item. 2. It must be possible to indicate in XML Schema what media type the character content of an element ii will have. 3. It should be possible to specify a set of such media types, see the HTTP Accept header (RFC 2616). All this can be done specifically for the Representation header if it turns out a generic solution is too contentious or just not useful. 8-)[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP WG has closed issue 443 by stating the following: "We have the 'Assigning Media Types to Binary Data in XML' document. That provides the xmlmime:ContentType attribute to indicate the media type of content in XML and a schema annotation for indicating acceptable media types in a schema description." The Assigning Media Types to Binary Data in XML' is located at [2]. Please note that the attribute name used in [2] is 'mediaType' and not 'ContentType'; this will be changed in a newer version of the 'Assigning Media Types to Binary Data in XML' document.[email] |
|||||||
444 | mtom | n/a | meta | Design | Closed | Noah Mendelsohn | |
Title: MTOM and Data Model Details | |||||||
Description:
In Sept. I sent an email to distApp announcing that the data model formulation of MTOM was ready for consideration by the XMLP Workgroup [1]. Subsequently, the workgroup agreed to adopt the DM formulation. In the email, I raised some concerns that should have turned into issues, but apparently we never formally added them to the list. Specifically, see the paragraph that says: "At least one set of details remains to be resolved if the DM formulation is to be used: the current draft does not discuss all of the accessors provided by the data model. For example, element nodes [5] provide a base-uri [6], which in principle can vary for each element. Future versions of the draft would need to explain that, like type information, such base URI and similar information is not transmitted. This limitation is consistent with the general philosophy that MTOM will transform the input data model to a different (but predictably different) output data model at the receiver. In general, the transmission will exactly preserve certain information, will lose other information such as base URI and type, and will not add or synthesize other information, except as directly follows from the losses (e.g. typed values change in the obvious way when type information is lost.)" So, as suggested on our telcon of today, this is a request to open an issue. I suggest that the issue be relatively broad, along the lines of "Do a thorough review of the DM, MTOM and if appropriate Miffy specs to ensure that all interdependency issues, including those raised in [1], have been dealt with in an appropriate manner."[email] |
|||||||
Proposal: | |||||||
Resolution:
The issue basically calls for XMLP to ensure that our specification of data model accessors in XOP is complete and accurate. We believe this was attended to at the San Francisco face to face [2], and the intention is that the editors will reflect details of that resolution in future working drafts[email] |
|||||||
445 | miffy | n/a | meta | Editorial | Closed | David Fallside | |
Title: the name "Miffy" | |||||||
Description:
The name "Miffy" is copyright by "Mercis bv", see http://www.miffy.com/. I recommend that after completing its technical work, the XMLP WG choose a non-encumbered name to replace "Miffy".[email] |
|||||||
Proposal: | |||||||
Resolution:
the WG has decided today at its telcon to change the name of the MIFFY spec to XOP - XML binary Optimized Packaging, thus resolving issue 445.[email] |
|||||||
446 | miffy | n/a | meta | Design | Closed | Noah Mendelsohn | |
Title: Miffy content in Miffy content | |||||||
Description:
When the scope of MTOM was SOAP-only, it seemed that the likely rule would be: Don't use xbinc:include in the SOAP envelope, it's for use by bindings. Now that we are considering miffy, there are questions about including one miffy-based format in another. Here's a concrete if somewhat contrived example: a) imagine a vcard-like XML format that allows inclusion of someone's picture. Enable that for miffy so that the picture can be carried efficiently. b) Question: can you carry such a vcard as part of the content of a soap body or header? What are the miffy processing rules of that SOAP envelope is itself Miffy encoded? This seems to be an example of a more general issue, relating to the combination of miffy-enabled formats. Of course, this is all somewhat complicated by the somewhat strange relationship of the application/soap_mtom_xml media type to the surrounding multipart/related.[email] |
|||||||
Proposal: | |||||||
Resolution:
You raised issue 446 regarding whether MIFFY/XOP can serialize a data model that already contains xop:Include elements. The XMLP WG adopted the following text into Section 3 of the XOP document: Note that the data model used as input to XOP processing MUST NOT contain any element nodes with a dm:node-name {http://www.w3.org/2003/06/soap/features/binary-inclusion;Include}; data models containing such elements cannot be serialized using XOP.[email] |
|||||||
447 | mtom/miffy | n/a | meta | Design | Closed | Noah Mendelsohn | |
Title: recognizing and processing MTOM/Miffy in the HTTP Binding | |||||||
Description:
As requested at the f2f, this note is to remind us that we (should) have an open issue to determine how a SOAP HTTP implementation, receiving whatever content type we eventually decide on for MTOM, will make the determination to do MTOM processing. We must then make suitable updates to the HTTP section of the MTOM document.[email] |
|||||||
Proposal: | |||||||
Resolution:
You raised an issue, give the number 447[1] with respect to how an MTOM/XOP aware SOAP node will make the determination as to whether or not to perform MTOM/XOP processing. The XMLP working group have decided that such processing will be triggered by the media type of the outer package, which in the MTOM case will be application/soap_xop+xml[email] |
|||||||
448 | mtom | n/a | meta | Design | Closed | David Orchard | |
Title: extensibility/versioning in mtom elements | |||||||
Description:
What is the extensibility and versioning strategy for mtom elements? Do we allow extensibility of attributes and/or elements, and if so, what is the processing model for extensions? What is the policy related to the miffy namespace name for future elements and/or attributes? I have some thoughts on the right way to do this at http://www.w3.org/2001/tag/doc/versioning-20031003[email] |
|||||||
Proposal: | |||||||
Resolution:
The xop:Include element allows extension attributes and child elements, as long as they may be safely ignored during processing. See the current Editors' Draft for the exact wording the WG intends.[email] |
|||||||
449 | mtom | n/a | meta | Design | Closed | Marc Hadley | |
Title: Multiple representations of a single resource | |||||||
Description:
Can a message contain multiple representations of the same resource using the MTOM representation mechanism. E.g. can a message contain JPEG and PNG renditions of the same resource using the MTOM representation mechanism.[email] |
|||||||
Proposal: | |||||||
Resolution: It's OK for two Representation headers in a message to have the same URI and role and decided to add a note saying that such headers would typically have different metadata. [email] | |||||||
450 | miffy | n/a | meta | Design | Closed | Chris Lilley | |
Title: Referenced parts MUST include the 'Content-Transfer-Encoding' field and should include the 'Content-Length' field. | |||||||
Description:
1) Referenced parts MUST include the 'Content-Transfer-Encoding' field and should include the 'Content-Length' field. The MIFFY description as presented in the above referenced document presents a sound approach to encoding of compound or multipart payloads. It appears that the described encoding mechanism from SOAP data into MIME encoded multipart will produce arbitrary binary data for the encoded MIME sub-parts. In particular, when control characters, i.e. less than 32 decimal are encoded in base64, they will decode into raw control characters in the MIME part. The NUL (0x00) character in particular will very probably be problematic. MIME sub-parts encoded in such a manner assume an 8-bit clean transmission channel, which may not be available for general application of such an encoding. In the presence of an 8-bit clean channel, there must be a workable mechanism to allow the inclusion of arbitrary binary data. Such binary data may by its very nature include a valid MIME part delimiter. The mechanism for inclusion of arbitrary binary data inside a MIME sub-part is addressed in RFC 2045 by use of the 'Content-Transfer-Encoding' field with a parameter specified as 'binary'. In the case of using the 'binary' encoding, the MIME header MUST include a 'Content-Length' field indicating the number of bytes of raw binary data present in the sub-part (as specified in RFC 2543 etc.). It is our suggestion that the 'Content-Transfer-Encoding' and 'Content-Length' fields be present in all MIME sub-parts encoded using the MIFFY encapsulation. At minimum the contained data should be analysed for compatibility with non-binary transport gateways and the sub-part encoded using a well specified 'Content-Transfer-Encoding', be that base64, etc. For simplicity of encode/decode we would suggest that 'Content-Transfer-Encoding' and 'Content-Length' be mandatory in a MIFFY encoded sub-part and that the encoding be 'binary'. Note, that the CIP4 group using JDF already use such a scheme for transmission of multipart aggregated print jobs in pre-press production areas. In the absence of an 8-bit clean transmission channel, MIFFY should specify a preferred encoding mechanism for the sub-parts, most probably base64. In any case, transcoding at gateways should be possible.[email] |
|||||||
Proposal: | |||||||
Resolution: Closed with no action [email] | |||||||
451 | miffy | n/a | meta | Design | Closed | Chris Lilley | |
Title: referencing mechanism via 'Content-Type' and 'http' URI | |||||||
Description:
2) The referencing mechanism via 'Content-Type' and 'http' URI presents an ambiguous referencing mechanism and may require removal. The process of encoding a SOAP packet into an aggregated MIME multipart specifies two alternate encodings for referenced content. One uses the well-known 'cid:' URI which references the MIME sub-part by use of 'Content-Id' in the sub-part. An alternate referencing mechanism by use of an 'http:' URI and specification in the MIME sub-part by use of the 'Content-Location' field. This latter mechanism seems to present a potential ambiguity in its semantics. Firstly, if the process is a recoding mechanism, it is entirely unclear why two alternate schemes are needed. The 'cid:' referencing mechanism is well known and functional. An encoder can unambiguously encode content via this mechanism. The second mechanism via the use of 'http:' seems to be semantically incorrect. The specification of an 'http:' address in the XML content in the root part of the MIME package implies that an 'http:' request should be made to retrieve the referenced content. This is clearly not the desired behaviour. A greater concern is in malformed encodings where a matching MIME sub-part cannot be found. Should the decoder attempt to fetch the resource via 'http:'? If so, the message itself is in error, as the resources are not present in the packaged message. Also, should a decoder check if the referenced content is up to date, or just use the encapsulated MIME sub-part instead? The use of 'http:' as a referencing mechanism seems to be at odds with what the encoding represents. Placing a 'Content-Location' header field in the MIME sub-part is possibly useful as metadata, however we would suggest that the 'cid:' referencing mechanism be mandatory.[email] |
|||||||
Proposal: | |||||||
Resolution: The XMLP WG have resolved this issue by mandating that the cid: scheme must be used. [email] | |||||||
452 | miffy | n/a | meta | Design | Closed | Chris Lilley | |
Title: Addressing the 'data:' URI directly in the MIFFY specification | |||||||
Description:
3) Addressing the 'data:' URI directly in the MIFFY specification is desirable. As currently defined, MIFFY may only optimise base64 data found as element content. In order to accommodate common practice in a number of vocabularies, notably SVG where it is a frequent occurrence, we believe that there would be great value in supporting data: URIs (RFC 2397) in MIFFY, through the addition of appropriate markup to your vocabulary. This would effectively allow us to use MIFFY directly, without requiring any backwards-incompatible change to SVG. We understand that XMLP may wish to without this feature in the SOAP context, but it appears to us that MTOM could profile MIFFY to eliminate it if you are so inclined.[email] |
|||||||
Proposal: | |||||||
Resolution: the XMLP WG has decided at its face-to-face meeting last week to close issue 452 regarding optimizing data: URIs in attributes by declining to add support for this in XOP. We don't consider data: URIs a good use case to design our optimization mechanism for. [email] | |||||||
453 | miffy | n/a | meta | Design | Closed | Chris Lilley | |
Title: Packaging multipart payloads via use of the 'multipart/multiplexed' mechanism in RFC 3391 should be considered as valid MIFFY encoding mechanism | |||||||
Description:
4) Consideration of packaging multipart payloads via use of the 'multipart/multiplexed' mechanism in RFC 3391 should be considered as a valid MIFFY encoding mechanism. In some use cases, it is desirable to interleave the base XML document data with its referenced content. A mechanism for doing so is described in RFC 3391. It is our opinion that the mechanism described in RFC 3391 be a valid encoding mechanism for MIFFY encoded documents. It presents little overhead for decoders and has the desirable benefit of facilitating streamed content with multiple referenced parts.[email] |
|||||||
Proposal: | |||||||
Resolution: The XMLP WG has resolved this issue by deciding that XOP will allow use of RFC3391 although it will not define such a serialization. MTOM will mandate use of multipart/related. To use RFC3391 in SOAP, an RFC3391 based 'MTOM' spec would need to be written. [email] | |||||||
454 | miffy | n/a | meta | Design | Closed | Noah Mendelsohn | |
Title: variability of encoding in Miffy | |||||||
Description:
I had always assumed that in Miffy, all the parts except the root would be octet streams, probably labeled as application/octet-stream and sent in 8-bit format. Anish mentioned on the call today his assumption that a range of representations would be allowed on the wire, providing that content-transfer-encoding would be correctly set to indicate the representation used. The tradeoffs appear to be: a) variability is more flexible b) variability requires that all receivers/interpreters be capable of decoding all encodings if universal interop is to be achieved c) neither of us was sure whether the decision to fix the representation might be taken as a misuse of MIME.[email] |
|||||||
Proposal: | |||||||
Resolution: The XMLP WG have resolved this issue by saying that in the MTOM HTTP binding each binary part MUST have a content-transfer encoding of binary. [email] | |||||||
455 | mtom | n/a | meta | Design | Closed | Noah Mendelsohn | |
Title: SOAP processing model and Representation Header | |||||||
Description:
This relates in part to issue 442 and to the proposed resolution [2]. The proposed resolution must be augmented, IMO, to describe its use of the SOAP processing model. I believe this will result in our specfying some rules for when a conforming implementation may use the representation header to resolve a retrieval request for a resource. Consider and example of an original sender, final destination and two intermediaries: S -> A -> B-> D If a representation header is addressed to the final destinatino D (default SOAP role), should a retreival request at A use it? I would think not, as that would be circumventing the usual mustUnderstand mechanisms of SOAP. If I want to specifically cause two different representations, of the same media type for the same resource, to be sent to A and B respectively, can I safely use multiple representation headers that differ in their soap:roles to do this? I would think so. In any case, I believe we must decide on and document the rules we want. The current proposal refers a bit to mustUnderstand, but doesn't really cover the rules in detail. I propose that we open a new issue to track this question.[email] |
|||||||
Proposal: | |||||||
Resolution:
The text describing the Representation Header will state: 1. "The type of the reinsert attribute information item is xs:boolean . When this attribute is specified on the Representation header block with a value of "true", it indicates that a SOAP forwarding intermediary node processing the header block must reinsert the header block. This means that when used in conjunction with the relay attribute, defined in [SOAP Part 1] 5.2.4 SOAP Relay Attribute, with a value of "true", the Representation header block will always be relayed by a SOAP forwarding intermediary. When this attribute is specified on the Representation header block with a value of "false", the behavior of the SOAP node processing the header block is the same as that when the attribute is not specified, and normal SOAP processing rules apply. The presence of this attribute has no effect on the processing of a Representation header by a SOAP endpoint." 2. The reinsert attribute is not namespace qualified. 3. "Such Representation header blocks SHOULD NOT have the same metadata (such as media-type). If such Representation header blocks have the same metadata then any one of them may be used." 4. Implementations MAY need to process Representation header blocks BEFORE other header blocks that might dereference URIs.[email] |
|||||||
456 | mtom | n/a | meta | Design | Closed | Herve Ruellan | |
Title: constraints on nodes types | |||||||
Description:
- Context Currently, section 3.1 [2] of MTOM [1] states: <current> For use with this serialization, the type property MUST be set to xs:base64Binary only for those Element Nodes known to be in the canonical lexical form for that type. The type property for all other Element Nodes MUST be set to xdt:untypedAny. </current> - Problem 1 In the last sentence, "all other" refers to Element Nodes whose content is not base64-encoded data in canonical lexical form. I think that the current constraint on those Element Nodes is too strong: the only thing we need to ensure is that for those "other" Element Nodes, their type property is not set to xs:base64Binary. A use case where the current constraint is inconvenient is when a user wishes to send a full fledged Data Model with precise type information on all the Element Nodes (for example a Data Model resulting from a query in a database). In such a case, with the current formulation, the user would have to remove all type information from his Data Model (expect for xs:base64Binary typed Element Nodes) before sending it with an optimized SOAP binding. - Problem 2 Moreover I think that the first sentence may be somewhat unclear about our real intent. I think we want to allow for Element Nodes with base64-encoded content in canonical lexical form NOT to be tagged with an xs:base64Binary type. In such a case, the Element Node will not be optimized. - Proposal Therefore I propose to remove those two sentences as I think that sufficient constraints are described in 2.3.1 which is refered to just before those sentences.[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP WG agreed to remove the sentence "The type property for all other Element Nodes MUST be set to xdt:untypedAny." from the spec.[email] |
|||||||
457 | mtom | n/a | meta | Design | Closed | Yves Lafon | |
Title: Extension required for the Representation header | |||||||
Description:
The current resolution of issue 442 [1] allows extensions to provide protocol-dependent metainformation and context, but nothing is defined. An extension for HTTP (the most common case) or a subset of MIME-based protocol. One use case is an automatic update of a mesh of HTTP caches where a notification can carry a HTTP entity body and all meta-information (and context) needed for a HTTP cache.[email] |
|||||||
Proposal: See email | |||||||
Resolution: The XMLP WG decided to close issue 457 by adopting the proposal at [email] and including it in the Representation header. [email] | |||||||
458 | mtom/xop + REC | n/a | meta | Design | Closed | Noah Mendelsohn | |
Title: impact of XML 1.1 | |||||||
Description:
Now that XML 1.1 is a recommendation, and allows characters not allowed in XML 1.0, it seems to me we need a review of our entire recommendation, as well as XOP and MTOM drafts, to make sure we are clear on issues such as: Are the new control characters allowed by XML 1.1 allowed in XML SOAP Envelope infosets? If so, do you indicate this in the version of the Infoset Document Information item? If allowed, I don't see how the HTTP binding would send them using the usual RFC 3203-based serialization, which my quick reading shows as XML 1.0. We refer in the rec to XML 1.0 whitespace, but XML 1.1 allows NEL (x85) as whitespace. Are we at least clear as to what is whitespace and what isn't for SOAP? Is it legal to write a new binding or media type that sends the new control chars, perhaps using XML 1.1 serialization? This would seem to break the equivalence among bindings. We should similarly make sure XOP and MTOM are clear on these issues.[email] |
|||||||
Proposal: [email to kick off discussion, with links to details] | |||||||
Resolution:
a) that the infoset for a SOAP message may use any recommendation level version of XML ( which at the time of writing encompasses XML 1.0 and XML 1.1 ). b) that bindings may restrict themselves to a particular version ( or versions ) of XML for serialization. c) that the application/soap+xml media type ( and hence the SOAP 1.2 HTTP binding ) will be restricted to XML 1.0 serialization. only. d) that the application/soap_xop+xml media type ( and hence the MTOM binding ) is similarly restricted to XML 1.0 serialization.[email] |
|||||||
459 | mtom/xop | n/a | meta | Design | Closed | Carine Bournez | |
Title: Requirements R9 and R7 | |||||||
Description:
During last teleconference, I took an action to open issues regarding requirements R9 and R7, to ensure that they are actually met by the MTOM/XOP specifications. -- R9 The specification must describe its points of extensibility. -- R7 The URI identification scheme must be robust under the addition and deletion of parts -- i.e., it must not require that URIs to other parts be altered, it must be relatively easy to avoid URI conflicts, etc. See Use Cases and Requirements and M.Mahan's email.[email] |
|||||||
Proposal: | |||||||
Resolution: Closed and splitted in issue 463 and 464. [email] | |||||||
460 | xop | n/a | meta | Design | Closed | Erik Wilde | |
Title: let the implementation decide to create a part? | |||||||
Description:
In section 4.1 (creating xop packages) shouldn't it be left to an implementation to decide whether creating a part is worth the effort? as i understand them, the current rules specify that every base64Binary node must be optimized, which can increase rather than decrease message size for small binary parts.[email] |
|||||||
Proposal: | |||||||
Resolution:
You raised an issue, 460[1], with respect to allowing implementations to choose when to optimize. The working group are amending the text you commented on to address this issue, amongst others. As an aside, I would note that the notion of starting with base64 and optimizing to binary is a specification convention. We actually expect that people will often start with the binary data and that it is just at the logical level that the base64 characters exist.[email] |
|||||||
461 | xop | n/a | meta | Design | Closed | Erik Wilde | |
Title: restricted subtypes of base64Binary | |||||||
Description:
When designing xml schemas, i usually avoid using xml schema built-in types and create a layer of my own simple types, which then are used in instances. i do this to be able to restrict all simple types, for example with length facets. wouldn't it be desirable to be able to optimize base64Binary and restricted subtypes, rather than base64Binary only? as i currently understand xop, my xml instances would not be optimized at all, because they use types derived from base64Binary. or would this be a requirement for my own type augmentation software, to generate the appropriate type information so that xop optimization works for base64Binary and derived subtypes?[email] |
|||||||
Proposal: | |||||||
Resolution: You raised an issue, 461, with respect to optimizing types that are subtypes of xs:base64binary. The working group plan to amend the text of the spec to address this issue, amongst others. Specifically in this case, the spec will no longer talk about types in terms of value space, but will talk about the character children of a given element being in the canonical lexical form of xs:base64Binary. As any subtypes of xs:base64Binary can be serialized in this form, we trust this addresses your concern. [email] | |||||||
462 | xop | n/a | meta | Design | Closed | Erik Wilde | |
Title: Whitespace in base64Binary | |||||||
Description:
Just out of curiosity: what happens with whitespace in base64Binary data? as i understand it, canonical base64Binary data may not contain any whitespace. is this intentional, because i think that many base64Binary does contain the linefeed characters required by rfc 2045. whitespace certainly would disappear in xop, and as i understand it, it cannot be reconstructed in the reconstituted dm. not that i think this would be a requirement, but i think this whole issue of whitespace in base64Binary data should be mentioned in the document.[email] |
|||||||
Proposal: | |||||||
Resolution:
In XMLP issue 462 you are concerned with base64 data in the infoset that contains whitespace; and the handling of such data in XOP. The WG has resolved to close your issue by accepting the following explanation and adding it where appropriate in the specs' introduction chapters. The primary use-case for XOP is that an application wants to include a chunk of binary data (that the application has as an octet stream, not encoded for example as base64) in an XML document in some optimized form. Where XOP requires canonical base64 data, that is only a conceptual requirement, it is expected that any implementation will skip encoding the original data into the infoset (or data model) but will pass the data directly to the XOP layer which will put it directly into the MIME envelope. Conceptually therefore, the data may be viewed as present in the infoset in base64 canonical, even if the implementation doesn't contain any base64-encoding code. For the other use cases where the base64 form is actually used, we must choose one unambiguous form (because we are required to reconstruct the precise infoset at the receiving end), and we chose to reuse XML Schema's canonical form (yet to be published?).[email] |
|||||||
463 | mtom/xop | n/a | meta | Design | Closed | Carine Bournez | |
Title: Requirements R7 | |||||||
Description:
During last teleconference, I took an action to open issues regarding requirements R9 and R7, to ensure that they are actually met by the MTOM/XOP specifications. -- R7 The URI identification scheme must be robust under the addition and deletion of parts -- i.e., it must not require that URIs to other parts be altered, it must be relatively easy to avoid URI conflicts, etc. See Use Cases and Requirements and M.Mahan's email.[email] |
|||||||
Proposal: | |||||||
Resolution: The XMLP WG decided to close issue 463 since it is straightforward to generate unique identifiers for each part (given the use of the cid: scheme to identify each part). [email] | |||||||
464 | mtom/xop | n/a | meta | Design | Closed | Carine Bournez | |
Title: Requirements R9 | |||||||
Description:
During last teleconference, I took an action to open issues regarding requirements R9 and R7, to ensure that they are actually met by the MTOM/XOP specifications. -- R9 The specification must describe its points of extensibility. See Use Cases and Requirements and M.Mahan's email.[email] |
|||||||
Proposal: | |||||||
Resolution:
The XML Protocol Working Group has closed issue 464 ("Requirements R9") by adding an appendix documenting XOP's relationships to other specifications, including its extensibility mechanisms.[email] |
|||||||
465 | xop | n/a | meta | Editorial | Closed | Frank Mabry | |
Title: XOP: spelling error or new term? | |||||||
Description:
In the fifth paragraph of the XOP working draft (http://www.w3.org/TR/2004/WD-xop10-20040209/) I think you have a minor typo: XOP is designed to carry sufficient information to reconstruct with full fidelity the supplied Data Model, including the return value of the dm:string-value accessor for each Node in the Data Model, except that the type property and the return value of the dm:typed-value accessor are generally not preserved. The type of base64Binary Element Bodes that were optimized is in fact conveyed, but the type of other Element Nodes as well as the type of Attribute Nodes is in general not preserved. In the last sentence I think that the "Bodes" reference could either have been a mistyped "Bodies" or "Nodes". But it leads me to a perfect word for some research I have been involved in with XML message types in the DOD. As I use it, "Bode" is a binary node hung in an XML tree that represents a reference to a payload digest element. I think that you will want to modify the online document but your word is perfect for covering a concept I had come up with for dynamic message compression. I guess this is a case of "thanks for the error!"[email] |
|||||||
Proposal: | |||||||
Resolution:
The WG resolved to take no action since the text to which you referred no longer exists in the current XOP document.[email] |
|||||||
466 | xop | n/a | meta | Design | Closed | Frank Mabry | |
Title: MTOM: Counter intuitive requirement | |||||||
Description:
W3C Working Draft 09 February 2004 Section 4.3.1 Sending a SOAP message The XOP package is constructed as described in 3. An Optimized MIME Multipart Serialization of SOAP Messages with the following restriction: * Each optimized Node MUST generate exactly one extracted binary part in the resulting package, i.e., extracted binary parts MUST NOT be referenced with more than one xop:Include in the SOAP message part. If transmission optimization is the goal of this effort, why do you specifically disallow reuse of a binary package that has been isolated in the document? I realize this may make some processing models more complex but the potential benefit is very significant. Messaging in military systems tends to have repeated information (the exact value of which is not predictable in advance but which reoccurs daily in many messages of all types). When a value (such as GPS, time, call-sign, unit-id) is used it is often repeated. While XML design considerations might allow reuse of the information via ID and IDREF, the influence of legacy systems (an environment that would not accommodate such referential complexity very well) continues to make such an alternative infeasible. Independent of my operational concerns for the Army, it does seem that you would want to recognize that an optimization of the message transmission should allow the potential for re-use of a defined binary representation when an opportunistic optimizer "discovers" it.[email] |
|||||||
Proposal: | |||||||
Resolution:
You raised an issue[1] regarding XOP and the cardinality of binary parts to xop:Include elements. The text you highlighted is no longer in the XOP specification, hence the restriction no longer applies in XOP itself. While such a restriction does exist in the MTOM specification at the level of the HTTP binding, other bindings of XOP can be constructed that do not have the restriction.[email] |
|||||||
467 | Representation | n/a | meta | Design | Closed | Michael Champion | |
Title: SOAP Representation Header, use cases needed. | |||||||
Description:
This spec needs more explicit statement of some use cases, and this is causing some confusion expressed in various weblogs and on the TAG mailing list. For example, some are calling it "tunneling HTTP over SOAP over HTTP". There would be no need for a Representation Header in an open HTTP environment where the recipient could dereference any links in a SOAP message, but this (perhaps overwhelmingly obvious) point is not made anywhere in the spec. Some use cases that come to mind (based on my hazy recollection of discussions when I was on the XMLP WG) would be: - A SOAP message that references Web resources needed to process it is received by an HTTP gateway and then passed over a proprietary messaging system (e.g. MQ) to a system that is not on the Web. -- A SOAP message that references Web resources needed to process it is received by the DMZ outside a high-security environment. All arbitrary Web links must be dereferenced and vetted outsize the high-security environment and passed inside for processing. - - A SOAP message that references Web resources needed to process it is received by a performance-critical system; tasks that can be easily parallelized (such as HTTP GETs on the links) are done simultaneously, and the results combined and passed downstream to a process that must consider them all. Do these make sense, or am I also missing the point here?[email] |
|||||||
Proposal: | |||||||
Resolution:
The XMLP WG considered your comment on their telephone conference this week and decided to amend the first paragraph of Section 2.1 to read: "The Representation header block is designed to allow applications to carry a representation of a Web resource in a SOAP message. Applications of this header include cases where the receiver has limited ability to get the representation using other means, for example because of access restrictions or because the overhead would be unacceptable. The representation header is also required when multiple references to the same extracted content are required but duplication of extracted content is undesirable. See UC 2 and UC 6 for details." where UC2 and UC6 will be bibliographic references to our use cases document.[email] |