Some editorial tweaks

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 Wednesday, 4 December 2002 13:14:01 UTC