Comments on 1st July draft of SMTOM

This is looking better. I have the following comments, mostly editorial.

Jean-Jacques.

--
1.
<current>
This Abstract Transmission Optimization Feature is intended to be 
implemented by SOAP bindings, however nothing precludes implementation 
as a SOAP module.
</current>

<proposed>
This Abstract Transmission Optimization Feature is intended to be 
implemented by SOAP bindings. Nothing precludes an implementation as a 
SOAP module; however, this specification does not specify such a binding.
</proposed>


2.
<current>
However, it may be expected that this specification will supersede the 
[SOAP 1.2 Attachment Feature] specification once this specification has 
reached a stable state.
</current>

<proposed>
s/may be/is/
</proposed>


3.
<current>
http://www.w3.org/2003/06/soap/features/abstract-optimization/OptimizationCandidates
<current>

URI is far too long.

<proposed>
Shorten URI.
</proposed>

<proposed>
Transpose the table. I.e. instead of:

----------------------
| prop_name1 | desc1 |
----------------------
| prop_name2 | desc2 |
----------------------

use:

==============
| prop_name1 |
--------------
| desc1      |
==============
| prop_name2 |
--------------
| desc2      |
==============
</proposed>


4.
<current>
To send a SOAP message using the Abstract Transmission Optimization 
Feature, an application MUST enable the Abstract Transmission 
Optimization Feature.
</current>

<proposed>
s/an application/a SOAP sender/
</proposed>


5.
<current>
When receiving a SOAP message using an implementation of the Abstract 
Transmission Optimization Feature, a SOAP node MUST fault if it does not 
support the implementation used or the Abstract Transmission 
Optimization Feature.
</current>

<proposed>
s/a SOAP node/a SOAP receiver/
</proposed>


6.
<current>
2.4.3 Transmitting a message
</current>

<proposed>
s/Transmitting/Relaying/
</proposed>


7.
<current>
The usage of the Abstract Transmission Optimization Feature is a 
hop-by-hop contract between a SOAP node and the next SOAP node in the 
SOAP message path.
</current>

<proposed>
s/between a SOAP node/
  /between a given SOAP sender/


8.
<current>
However a SOAP intermediary implementing the Abstract Transmission 
Optimization Feature MUST still follow the rules related to the usage of 
an implementation of the Abstract Transmission Optimization Feature when 
receiving the message (see 2.4.2 Receiving a message) and those related 
to the usage of an implementation of the Abstract Transmission 
Optimization Feature when sending the message (see 2.4.1 Sending a message).
</current>

Sentence is too long. Break into bullets.

<proposed>
However... MUST obey the following rules:
<item>...</>
<item>...</>
</proposed>


9.
<current>
3.2 Inclusion element
3.2.1 Include element
</current>

This gives the impression there are two elements, not one.


10.
<current>
one body part, the root, containing
</current>

<proposed>
the root body part contains
</proposed>


11.
<current>
Extract the SOAP message from the root object
</current>

<proposed>
s/root object/root body part/
</proposed>


12.
<current>
In all aspects not described in this section, the rules of the HTTP 
binding are not modified
</current>

In the errata for the SOAP 1.2 spec, we may wish to add that the SOAP 
1.2 HTTP binding MAY support other features.


13.
<current>
When receiving a SOAP message using the HTTP Transmission Optimization 
Feature, the HTTP binding MUST, at least logically, provide access to 
the reconstructed SOAP message infoset.
</current>

<proposed>
s/the HTTP binding/the sending HTTP binding/

Received on Thursday, 3 July 2003 08:06:10 UTC