RE: Some editorial tweaks

Marc and I went through the remaining of Gudge's issues for Part 1 and
here's what we think we (spec editors) need to do:

> 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.

First time in each part expand with what it really means.

> 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.

Marc to send out a note to the WG asking for guidance and also regarding
whether the sig stuff should go in appendix

> 13.	Section 5.1.1
> 
> 	For consistency the type information for the attribute should
> come immediately after the infoset properties

Just do it

> 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.

Do nothing

> 16.	Section 5.2.1
> 
> 	The relay AII is missing from the list of AIIs allowed on a
> header block.

Just do it

> 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

Just do it

> 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

Just do it

> 19.	Section 5.4.2
> 
> 	The constraint on the xml:lang attribute values should be in
> section 5.4.2.1

Nope, the constraint is on the parent. Do nothing.

> 20.	Section 5.4.2.1
> 
> 	For consistency the type information for the EII should come
> immediately after the infoset properties

Just do it

> 21.	Section 5.4.2.1
> 
> 	We need to add that the [prefix] property of the xml:lang
> attribute MUST be 'xml'

Just do it

> 22.	Section 5.4.3
> 
> 	For consistency the type information for the EII should come
> immediately after the infoset properties

Just do it

> 23.	Section 5.4.5.1
> 
> 	The language concerning allowable attribute should use the same
> style as we use for header and body blocks

Just do it

Henrik Frystyk Nielsen
mailto:henrikn@microsoft.com

>-----Original Message-----
>From: Jean-Jacques Moreau [mailto:moreau@crf.canon.fr] 
>Sent: Thursday, December 05, 2002 05:16
>To: Martin Gudgin
>Cc: W3C Public Archive; Marc Hadley; Nilo Mitra; Noah 
>Mendelson; Henrik Frystyk Nielsen
>
>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 Monday, 9 December 2002 17:29:15 UTC