From: Jean-Jacques Moreau <moreau@crf.canon.fr>

Date: Thu, 05 Dec 2002 14:15:36 +0100

Message-ID: <3DEF5178.3040800@crf.canon.fr>

To: Martin Gudgin <mgudgin@microsoft.com>

CC: W3C Public Archive <www-archive@w3.org>, Marc Hadley <marc.hadley@sun.com>, Nilo Mitra <EUSNILM@am1.ericsson.se>, Noah Mendelson <noah_mendelsohn@us.ibm.com>, Henrik Frystyk Nielsen <henrikn@microsoft.com>

Date: Thu, 05 Dec 2002 14:15:36 +0100

Message-ID: <3DEF5178.3040800@crf.canon.fr>

To: Martin Gudgin <mgudgin@microsoft.com>

CC: W3C Public Archive <www-archive@w3.org>, Marc Hadley <marc.hadley@sun.com>, Nilo Mitra <EUSNILM@am1.ericsson.se>, Noah Mendelson <noah_mendelsohn@us.ibm.com>, Henrik Frystyk Nielsen <henrikn@microsoft.com>

In addition, I've removed diff markup from the fault sections to the end of the spec, including the appendix (part 1 only). My next free slot is now Tuesday next week. Happy diffing, Jean-Jacques. Martin Gudgin wrote: > I read through Part 1 last night and noted that there are several things > that need editorial attention/clarification. Here is a list of the > things I noted, in the order they appear in the spec. BTW - I'm happy to > make all these changes sometime before close of business Monday. > > I'll send a separate mail concerning Part 2 later today > > Gudge > > > 1. Section 1.5.1 > > The definition of SOAP Module has "*zero*" in the paragraph. > What is the significance of the asterisks? > > > 2. Section 2 > > The third paragraph begins with the word 'It'. What is 'It'? I > *think* it's 'The SOAP Processing Model' but from context it could be > interpreted as 'This section' > > > 3. Section 2.2 > > In the third paragraph after table 2 "role names defined above" > should read "role names define in Table 2" where Table 2 is a specref. > > 4 Section 2.6 > > Bullet 3 should be reworded to be clearer and use infoset terms. > "The Value of Code" seems ambiguous in the current langauge. > > 5. Section 2.7.2 > > The first paragraph after the numbered list ends with the word > 'above'. 'above' what? I would suggest we change 'above' to 'by the > intermediary' > > 6. Section 2.7.4 > > In Bullet 1, "can be removed from" should read "can be removed, > by that intermediary, from" > > 7. Section 2.7.4 > > In Bullet 1 "[ref to header block processing rules]" should be a > specref > > 8. Section 2.7.4 > > In Bullet 2 "[ref to header block processing rules]" should be a > specref > > 9. Section 2.7.4 > > It would be nice to add a note saying that these 18 exceptions > are based on a 'writer makes right' approach and that a canonicalization > algorithm ( a reader-makes-right ) approach would obviate the need for > them. > > 10. Section 3.2 > > The two numbered bulleted items seem to be duplicate information > from the earlir (unnumbered) bulleted list in this section. > > 11. Section 3.3 > > The first paragraph has "*zero*" in it. What is the significance > of the asterisks? > > 12. Section 5 > > There is text missing concerning the fact that if we don't > specify a value for a given infoset property then any legal value is > acceptable. > > 13. Section 5.1.1 > > For consistency the type information for the attribute should > come immediately after the infoset properties > > 14. Section 5.1.1 > > I think it would be better to reword the MUST NOT / MAY for > where encodingstyle can appear as follows: > > The encodingStyle AII MAY appear on the following: > > <list as currently in spec> > > The encodingstlye AII MUST NOT appear on any other elements in a > SOAP Message Infoset > > 15. Section 5.1.1 > > It is implied but not explicitly stated that nested > encodingstyle override ancestor declarations. For clarity, I think there > should be some explicit statement. > > 16. Section 5.2.1 > > The relay AII is missing from the list of AIIs allowed on a > header block. > > 17. Section 5.2.2, 5.2.3, 5.2.4 > > We use different language in 5.2.2 concerning intermediaries > dropping these attributes than we do in 5.2.3 and 5.2.4. We should be > consistent > > 18. Section 5.2.2, 5.2.3, 5.2.4 > > Concerning what changes intermediaries make to these attributes > I think it would be good to reference 2.7.4 > > 19. Section 5.4.2 > > The constraint on the xml:lang attribute values should be in > section 5.4.2.1 > > 20. Section 5.4.2.1 > > For consistency the type information for the EII should come > immediately after the infoset properties > > 21. Section 5.4.2.1 > > We need to add that the [prefix] property of the xml:lang > attribute MUST be 'xml' > > 22. Section 5.4.3 > > For consistency the type information for the EII should come > immediately after the infoset properties > > 23. Section 5.4.5.1 > > The language concerning allowable attribute should use the same > style as we use for header and body blocks > > 24. Section 5.4.7 > > SupportedEnvelope should be a sub-section. 'described below' > should be a reference to that sub-section > > 25. Section 5.4.7 > > qname AII should be a sub-section. > > 25. Section 5.4.7 > > The note at the end of section 5.4.8 also applies here. > > 26. Section 8. > > 'Johnathan Marsh' should be 'Jonathan Marsh' >Received on Thursday, 5 December 2002 08:16:36 UTC

*
This archive was generated by hypermail 2.3.1
: Wednesday, 7 January 2015 14:42:17 UTC
*