XML Protocol WG Proposed Recommendation Issues List

  Test T20 [1] is outdated, I believe. Immediate child elements of the SOAP
  Body element no longer must be qualified [2].
    

The WG decided to remove test T20 from the SOAP Version 1.2 
Specification Assertions and Test Collection document [3] in order to 
resolve the issue.
This will be reflected in the next editor's copy of the SOAP Version 1.2 
Assertion and Test Collection document.
  

It may be a good idea to mention that there is another possible outcome for
the second of the three cases ([1], omitted parameter), which is that the
receiver may fault [2]. This case is also covered by test XMLP-2 
[3] in the Test Collection.
    

T77 is specifically designed to test assertion 2-complexenc-nil, and has 
semantics designed to suit the same (which does require missing 
parameter to be responded with a non-fault SOAP response). Given the 
high bar set for making changes to PR documents, the WG decided to 
resolve the issue by maintaining status quo.
  

The recently posted proposed recommendation of SOAP Version 1.2 
Messaging Framework 
http://www.w3.org/TR/soap12-part1/#soapinterminfoset further 
restricts the legal content of SOAP messages that what is generally known:

Comment information items MAY appear as children and/or descendants 
of the [document element] element information item but not before or 
after that element information item.

In other words, SOAP messages cannot contain comments in either the 
prolog or epilog of a document. This was inferrable from the previous 
December 2002 working draft, but was stated in much less obvious 
language.

If I had to guess, I'd say this is an attempt to allow multiple SOAP 
messages to be stuffed into a single file or stream with clear 
boundaries between them. Whether that's a good idea or not, I don't 
think such a major change should be tossed out without further 
analysis and debate. This could introduce problems for various tools 
such as editors that like to stick a "credit" comment in the prolog 
of a document. This spec should go back to last call WD.
    

The working group considered this issue and decided to close the 
issue with no action. The grounds for this decision are as follows:

1.      As you observe there is no change here between the CR[3] and
PR[2] specification documents in terms of their position regarding
Comment Information Items in a SOAP message infoset.

2.      SOAP messages can still be processed using standard XML parsers.

3.      There are any number of other things one could put in an XML
Infoset that would cause that Infoset to be illegal per the SOAP
specification. For example, the [document element] having a [local name]
property with a value other than 'Envelope'.

4.      There is no requirement that SOAP messages be creatable/editable
with all existing XML tools.
  

Example 8a in section 4.1.1 of the Primer is incorrectly described. 
The example is

GET /travelcompany.example.org/reservations?code=FT35ZBQ  HTTP/1.1
Host: travelcompany.example.org
Accept: text/html, application/soap+xml

The explanatory text is "The HTTP Accept header is used to indicate 
the preferred representation of the resource being requested, which 
in this example is an "application/soap+xml" media type for 
consumption by a machine client, rather than the "text/html" media 
type for rendition by a browser client for consumption by a human."

However, there is nothing in Example 8a that indicates that 
application/soap+xml is preferable to text/html. The client indicates 
that it is willing to accept either one with equal priority (the 
default q=1). In order to indicate that application/soap+xml is 
preferred the example shoudl either remove text/html from the Accept 
header completely or adjust the relative q values of the MIME types 
accepted. For example,

GET /travelcompany.example.org/reservations?code=FT35ZBQ  HTTP/1.1
Host: travelcompany.example.org
Accept: text/html; q=0.5, application/soap+xml
    

The XMLP group discussed your comment and has agreed to accept your second suggestion 
to include the q value to indicate the preference for the application/soap+xml media type. 
This will be reflected in the next editor's copy of the Primer.
  

In the document SOAP Version 1.2 Part 0: Primer with status of Proposed 
Recommendation, I noted the following issue.

In Example 4, the xml declaration is <?xml version='1.0' ?> without any 
encoding attribute, therefore the value of encoding defaults to utf-8.  
Within the same soap message, an element is found with french characters.

<n:name xmlns:n="http://mycompany.example.com/employees">
          Åke Jógvan Øyvind
</n:name>

This is incorrect according to the XML 1.0 Recommendation unless the 
characters are escaped with the values.  According to my knowledge, two 
things could be done at this point by modifying Example 4's text:

	   1.) Add an encoding attribute to the xml declaration 
	   <?xml version='1.0' encoding='ISO-8859-1' ?>

	   2.) Change the element to
	   <n:name xmlns:n="http://mycompany.example.com/employees">
	             &#197;ke J&#243;gvan &#216;yvind 
	    </n:name>

making it a well formed xml document (due to assumption of encoding="utf-8")
    

You raised an issue against the SOAP 1.2 Part
0 Proposed Recommendation regarding the use of the XML declaration in
examples. After the ensuing e-mail discussion[3] on xml-dist-app the WG
concurs with your conclusion[4] that there is no issue to answer.
  

Are the following messages semantically equivalent (namespace 
declarations omitted for brevity)?
    <S:Envelope>
        <S:Header></S:Header>
	<S:Body><tns:foo/></S:Body>
    </S:Envelope>
and
    <S:Envelope>
	<S:Body><tns:foo/></S:Body>
    </S:Envelope>

In other words, if there are no headers, are message processors allowed 
to insert/delete an empty Header element?  I believe the answer is yes, 
as I can't find text that says otherwise.  

And what if there are no EII's for the Body, can that be omitted?
    <S:Envelope>
        <S:Header><tns:foo/></S:Header>
    </S:Envelope>
and
    <S:Envelope>
    </S:Envelope>

This has implications for message normalization and the ability to sign 
SOAP messages.
    

You (indirectly) raised an issue ( classed number 428[1] ) against the
SOAP 1.2 Part 1 Proposed Recommendation[2] regarding whether a SOAP
intermediary can add a <soap:Header/> element to a SOAP message that
does not already have one. After some discussion the WG has decided to
amend the 3rd item in the numbered list[3] as follows:

    3. Element information items for additional header blocks MAY be
added to the [children] property of the SOAP Header element information 
item as detailed in 2.7.2 SOAP Forwarding Intermediaries. In this case, 
a SOAP Header element information item MAY be added, as the first member 
of the [children] property of the SOAP Envelope element information item, 
if it is not already present.

Prior to taking this decision we solicted input from implementers. All 
responses indicated that the above change would NOT impact existing SOAP 
1.2 implementations.

4.1.3 states:
 
 "Example 13 <http://www.w3.org/TR/soap12-part0/#Ref477488396111> is the
 same as that in Example 9
 <http://www.w3.org/TR/soap12-part0/#Ref47748839611> , except that the
 Request-URI has been modified to include the reservation code, which
 serves to identify the resource ..."
  
  Both examples use the same request URI.
  

You raised an issue which is a text/example disagreement involving examples 9 
and 13 in the SOAP Primer. Thank you for noting this discrepancy. The WG has 
resolved this with the following amendments to the Primer.

1. In example 9, replace the first line with:
POST /Reservations HTTP/1.1

2. Rewrite the 1st para following example 9 (>>deletions<<, <<additions>>) thus:

"Example 9 shows an RPC request directed at >>a specific reservation at << the travel 
service application. The SOAP message is sent in the body of a HTTP POST method 
directed at the URI identifying the >>specific reservation<< <<"Reservations" resource
on the server travelcompany.example.org>>. When using HTTP, the request URI indicates 
the resource to which the invocation is "posted". Other than <<requiring that>> it be a 
valid URI, SOAP places no formal restriction on the form of the request URI (see [RFC 2396] 
for more information on URIs). However, one of the principles of the Web architecture is 
that all important resources be identified by URIs. This implies that most well-architected 
SOAP services will be embodied as a large number of resources, each with its own URI. Indeed, 
many such resources are likely to be created dynamically during the operation of a service, 
such as, for instance, the specific travel reservation shown in the example. So, a 
well-architected travel service application >>will<< <<should>> have different 
URIs for each reservation, and SOAP requests to retrieve or manipulate those reservations 
will be directed at their URIs, and not at a single monolithic "reservations" URI, <<as
shown in Example 9>>.<< Example 13 in section 4.1.3 shows the preferred way to address
resources such as a particular travel reservation. Therefore, we defer until section 4.1.3 
further discussion of Web architecture compatible SOAP/HTTP usage.>>"

3. Delete the 2nd para following Example 9 (it will be moved and merged into section 4.1.3, 
see item 5 below).

4. Rewrite the 1st para **before** Example 13 (>>deletions<<, <<additions>>) thus:

"Example 13 is the same as that in Example 9, except that the <<HTTP>> Request-URI has been 
modified to include the reservation code, which serves to identify the resource (the reservation 
in question, which is being confirmed and paid for) >>, while the other parameters in the RPC, 
such as the creditCard number are ancillary data to be processed by the resource. Note, however, 
that all the resource-identifying elements have been retained as in Example 9 in their encoded 
form in the SOAP env:Body element<< . 

5. Add a **new** paragraph just **after** Example 13 with the following text (modified deleted text 
from item 3 above):

"In Example 13, the resource to be manipulated is identified by two things: the first is that it 
is a reservation (part of the method name), and the second is the specific instance of a reservation 
(which is the value of the parameter code to the method). The remainder of the parameters in the RPC 
such as the creditCard number are not resource-identifying, but are ancillary data to be processed 
by the resource. It is the recommendation of [SOAP Part2] that resources that may be accessed by 
SOAP-based RPCs should, where practical, place any such resource-identifying information as a part 
of the URI identifying the target of the RPC. It should be noted, however, that [SOAP Part2] does 
not offer any algorithm to do so. Such algorithms may be developed in future. Note, however, that 
all the resource-identifying elements have been retained as in Example 9 in their encoded form in 
the SOAP env:Body element."
  

The second paragraph of Section 5.4.8, SOAP mustUnderstand Faults, of
the SOAP Version 1.2 Part 1 PR states:

   A SOAP node MAY generate a SOAP fault for any one or more SOAP
   header blocks that were not understood in a SOAP message.  It is
   not a requirement that the fault contain the XML qualified names of
   all such SOAP message blocks.

The paragraph following Example 7 in the SOAP Version 1.2 Part 0 PR states: 

    If there were several mandatory header blocks that were not 
    understood, then each would be identified by its qname attribute in 
    a series of such env:NotUnderstood header blocks.

Perhaps 'would' should be 'could', since one env:NotUnderstood is okay 
when there's several header blocks that are not understood.
    

The WG resolved this issue by accepting the proposed change from
'would' to 'could' in the text of the Primer.
  

The following issue has been raised (e.g. [1]) on ws-arch: is there one 
and only one ultimate receiver, or can there be several ultimate 
receivers for the same message?

The issue is that multicast bindings, for example, may be prohibited if 
there is only one single ultimate receiver.

Currently, Part 1 specifies there can only be ONE ultimate receiver (THE 
ultimate receiver). An earlier version of Part 1 used to allow multiple 
receivers (AN ultimate receiver), as per the resolution to issue 103 [2].

It appears that when the resolution to issue 103 was implemented, not 
all occurences of "THE" were changes to "AN", and that an (unfortunate) 
editorial sanity check later replaced all instances of "AN" to "THE", 
instead of the contrary.

We have two options at this stage:

1) Go with whatever is in Part 1 today, considering that we are too late 
in the Recommendation process; or

2) Reimplement the resolution to 103 (i.e. s/THE/AN/).

I have a preference for option 2) above and consider that this is an 
editorial change only. However, I think we should first investigate 
whether this change is likely to (severely) impact current 
implementations. I don't think so, but at the same time I don't want to 
take the risk of delaying publication.

The working group discussed the issue and decided to close it with no action 
partly due to being very late in the process but mainly because there was no
desire amongst the WG to change the status quo.
  

I noticed that the printing problems linked to the large tables present 
in the SOAP 1.2 Part 2 specification where still remaining in the PER 
(see [1]). The issue is that as there are tables containing URIs in 
several columns, those tables are very large and do not fit on a page 
while printing.

Talking about this issue with Yves, he found that this issue had been 
solved in a previous edition of the PER (see [2]), but this modification 
seems to have been lost somewhere.

Could you change back the table layout to the one in [2] in the future 
editions of the specification?

The Working Group agreed with your comment and decided to incorporate the 
new table layout in the current editors' copy

application or context-dependent URIs (see RFC 2986 <bibref 
ref="RFC3986"/>).

2986 should be 3986

The working group agreed with the proposed text and is now in the editors' 
copy

In part 0:

One minor typo in section 1: "[ResRep]specifes" should be "[ResRep]
(specifies"

In part 2:

   A minor organizational point.  The specification seems to be of two
minds regarding whether MEPs are Features or something sui generis.  Part
I asserts that MEPs are Features; however, sections 7.3 and 7.4 (and
following sections) in Part II treats MEPs as something other than
Features.  The HTTP binding supports the following Features: 2 MEPs as
specified, web-method and action.  At a minimum, 7.4 should say that the
binding MUST support the following "additional" features.
	

The Working Group decided to close this issue (rec44) with the following 
resolution:

(in part 0)
> One minor typo in section 1: "[ResRep]specifes" should be "[ResRep]
> (specifies"

Fixed in the edcopy [1]

(in part 2)

> A minor organizational point.  The specification seems to be of two
> minds regarding whether MEPs are Features or something sui generis.  Part
> I asserts that MEPs are Features; however, sections 7.3 and 7.4 (and
> following sections) in Part II treats MEPs as something other than
> Features.  The HTTP binding supports the following Features: 2 MEPs as
> specified, web-method and action.  At a minimum, 7.4 should say that the
> binding MUST support the following "additional" features.

The working group decided to adopt the proposed resolution and the text in 
7.4 has been amended with "additional", see the edcopy in [2]