RE: SOAP Primer Review

Hello Marcel"
Thanks for your comments. If you look at the latest editor's copy [1], you will see that most of your comments have been addressed, particularly those on spelling. For the others, I have provided comments below on how I have handled them (deleting all inessential details). My comments are preceded by "NM:" Please let me know you have concerns about the resolution of these.
Thanks
Nilo 
[1]http://www.w3.org/2000/xp/Group/2/01/29/edcopy-soap12-part0-20020129.html

> 
> reviewed:
> SOAP Version 1.2 Part 0: Primer
> W3C Working Draft 17 December 2001
> 
> 
> Comments:
> 
> 1. 1 Introduction - first para, first sentence - same as the 
> last para,
> first sentence

NM: Not in the latest editor's version.

> 2. 1.1 Overview - there isn't a "Section 1"

NM; Don't know what you mean. Please explain.

> 3. 2.1 SOAP Messages - "A header is optional, but we have chosen to
> included it in our example." - it should be "include"

NM: Done.

> 4. 2.1 SOAP Messages - "...which seems to imply that this..."  I don't
> recall a "imply" verbage in other Primer's but I could be mistaken...

NM: "imply" because it isn't spelled out explicitly and is of the form of best practices.

> 5. 2.1 SOAP Messages - "...and represent some logical 
> grouping..." - remove
> "some"

NM: Not done. Would "a" be preferable?

> 6. 2.2 SOAP Processing Model - name of example should be more 
> verbose and
> less cryptic

NM: If by "name" you mean the "subject" as shown in the last line, it is meant to provide some hint on the example, but not to substitute for reading the text.


> 7. 2.2 SOAP Processing Model  - "The thrid header block"  - should be
> "third"

NM: Done.

> 8. 2.2 SOAP Processing Model  - "the header blockk 
> aThirdBlock" - should be
> "third"

NM: I don't understand. Perhaps you are correcting the misspelling "blockk'

> 9. 2.2 SOAP Processing Model  - The primer might want to be 
> explicit about
> not having a "actor" attribute value of "none" and a 
> mustUnderstand value
> of "true"

NM: Actually, the primer does not want to spell out all the edge cases. As this is allowed by the main specs, it is better for the primer, at this level, not to mandate or deny something.

> 10. 2.2 SOAP Processing Model  - The primer might want to be explicit
> example 1ter and the "actor" value of "next" and whether the final
> recipient of the SOAP message actually processes the "anotherBlock" -
> currently it just states: "It may process the header block 
> anotherBlock, as
> it is targeted at itself (in the role of "next") but it is 
> not mandatory to
> do so if the specifications for processing the blocks do not 
> demand it."  I
> refer to the "specification..." part - is this referring to a 
> TPA or is it
> referring to the final REC of SOAP? - can't tell by what is written

NM: I'm fraid i don't know the acronym "TPA" but i think the text is quite clear: "specifications for processing the blocks" cannot be the SOAP spec. Much has been already written about how the SOAp spec says nothing about the processing of blocks.


> 11. 2.3.2 - a few paragraphs in... "One possiblity is that such a URI
> identifying the target is carried in a SOAP header block. 
> Some protocol
> bindings, such as HTTP, offer a mechanism for carrying the 
> URI. " - should
> be "possibility"
> 12. 2.4 Fault Scenarios - "was the unlimate recipient of the 
> message which
> did so" should be "ultimate"

NM: Both corrected.

> 
> 
> 
> 
> 
> 
>