- From: Nilo Mitra (EMX) <Nilo.Mitra@am1.ericsson.se>
- Date: Tue, 16 Apr 2002 15:33:50 -0500
- To: "'xmlp-comments@w3.org'" <xmlp-comments@w3.org>
- Message-ID: <C358DED30DFED41192E100508BB3922701EE79D1@eamrcnt716.exu.ericsson.se>
originator didn't send his response to xmlp-comments. i'm forwarding for the record. nilo -----Original Message----- From: Marcel [mailto:marcel_jemio@yahoo.com] Sent: Thursday, April 11, 2002 5:39 PM To: Nilo Mitra (EMX) Subject: RE: SOAP Primer Review Thank you Nilo for your feedback - mine is inline below... Regards, -Marcel --- "Nilo Mitra (EMX)" <Nilo.Mitra@am1.ericsson.se> wrote: > 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. > Fixed... > > 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? > Yes. thank you. > > 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. > > OK. thank you. > > 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' > Yes. thank you. > > 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. > Ok. thank you. > > 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. > > T_rading P_artner A_greement. OK thank you. > > 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. > > > > > > > > > > > > > > > > __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/
Received on Tuesday, 16 April 2002 16:33:56 UTC