Re: Some editorial tweaks

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