XML Protocol WG Issues List

See the proposed resolution.

See the proposed resolution by Marc Hadley.

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.

1st design issue is use of port 80, 2nd design issue is 12, 3rd design issue is 14

This issue has not been resolved. A summary was prepared for Dinard, but not presented.

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.

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.

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.

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.

Will likely be considered in conjunction with issue 78

This issue should be considered in conjunction with issue 113.

  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. 

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.

Should multiref be top level or inline?

Refer also to issue 121 for a more detailed description.

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.

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.

First, we will tackle point 2.

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.

See Hugo's tracking on August 27th.

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).

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.

See discussion thread started by PaulC.

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.

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).

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.

Arrays can contain elements which themselves can be of any type, including nested arrays.

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.

Modularity at the Top
---------------------

Modularity at the Bottom
------------------------

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.
    

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.

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.

See Henrik's comment.

See Henrik's proposal.

R309 has been revised during the 14 November teleconference and Mark Baker will write a resolution text.

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.]

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.

"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."

"4.Provisions for specifying errors in a reply message (see also 703a and 703b)"

[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.

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.

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.

"Where possible, an attempt will be made to leverage any related work done by the IETF."

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.

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.

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.

[email

Result of the 14 November teleconference: postponed and assigned to TBTF.

 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.

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.

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.

See the proposed resolution text.

The definition of SOAP Intermediary in the glossary addresses this issue. [resolution text]

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.

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.

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.

This issue seems to be a combination of issue 12 (status codes) and clarification of when it's appropriate to use a Fault.

Will likely be considered in conjunction with issue 16

 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.<<

On today's conference call, the XMLP WG voted to close issue 82 [1] according to the resolution proposed in [2].

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.
    

The XMLP WG decided to close issue 87 with no action taken.  Th