- From: Jean-Jacques Moreau <moreau@crf.canon.fr>
- Date: Thu, 05 Dec 2002 14:16:23 +0100
- 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>
I'll be fixing some of these since I introduced them in the first place (*zero*). Plus a few more. Details below. Martin Gudgin wrote: > 1. Section 1.5.1 > > The definition of SOAP Module has "*zero*" in the paragraph. > What is the significance of the asterisks? Done. The asterisks in the original email were for empahising differences with the current text. > 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' Not in the copy I looked at. > 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. Done. I also had to remove all remaining references to the former Robustness section, since the spec no longer validated. > 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' Done. > 6. Section 2.7.4 > > In Bullet 1, "can be removed from" should read "can be removed, > by that intermediary, from" Done. > 7. Section 2.7.4 > > In Bullet 1 "[ref to header block processing rules]" should be a > specref Done. > 8. Section 2.7.4 > > In Bullet 2 "[ref to header block processing rules]" should be a > specref Done. > 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. I can't find this in 3.2 MEPs. > 11. Section 3.3 > > The first paragraph has "*zero*" in it. What is the significance > of the asterisks? Done. > 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 Done. > 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 Done. Also promoted the previous section. Also removed the diff markup. Also replaced "as described below:" by <specref...>. > 25. Section 5.4.7 > > qname AII should be a sub-section. Done. Copied the text for that section from 5.4.8, which also has a QName AII. > 25. Section 5.4.7 > > The note at the end of section 5.4.8 also applies here. Done as part of above. I also created subsections for 5.4.8, so the two sections are now symmetric, structure-wise. > 26. Section 8. > > 'Johnathan Marsh' should be 'Jonathan Marsh' Done.
Received on Thursday, 5 December 2002 08:17:05 UTC