FW: Proposals for remaining editorial spec issues

Forwarding...

-----Original Message-----
From: Martin Gudgin 
Sent: Sunday, August 25, 2002 19:53
To: Henrik Frystyk Nielsen; 'Marc Hadley'; 'Jean-Jacques Moreau';
'noah_mendelsohn@us.ibm.com'; 'Nilo Mitra'
Subject: RE: Proposals for remaining editorial spec issues




> -----Original Message-----
> From: Henrik Frystyk Nielsen
> Sent: 25 August 2002 09:42
> To: Martin Gudgin; 'Marc Hadley'; 'Jean-Jacques Moreau'; 
> 'noah_mendelsohn@us.ibm.com'; 'Nilo Mitra'
> Subject: Proposals for remaining editorial spec issues
> 
> 
> 
> Editorial Issues
> ----------------
> 
> 227 [0]
> 
> No action. I agree that the discussion thread is in
> accordance with the current text.

OK

> 
> 253 [1]
> 
> No action. XML base (and implicitly RFC 2396) does define the
> scope of a base URI.

+1

> 
> 279 [2]
> 
> No action. Section 2.7.2 already states that active
> intermediaries must follow the same rules as forwarding 
> intermediaries: "In addition to the processing performed by 
> forwarding intermediaries, active intermediaries undertake 
> additional processing that can modify the outbound message in 
> ways not described in the inbound message."

+1

> 
> 280 [3]
> 
> No action. The flexibility of the extensibility framework is
> explained in section 2.4: "Mandatory SOAP header blocks are 
> presumed to somehow modify the semantics of other headers or 
> body elements."

+1

> 
> 283 [4]
> 
> Ok with Gudge's proposal: Add enc:DuplicateID and modify
> prose accordingly 

+1, in fact this is already in the editor's copy

> 
> 284 [14]
> 
> Remove "binding-specific" in part 2, section 4. There is no
> reason that this address should be binding specific in any 
> way. The SOAP RPC representation is completely independent of this.

Ok with me, what do the other editor's think?

> 
> 289 [5]
> 
> No action. Reason is that we don't say anything about how the
> forwarding feature is defined for any SOAP messages other 
> than stating that it is a feature. This also apply to SOAP 
> faults--they are just a certain type of SOAP messages. 

Hmmm, I think people may have different expectation here, but I can live
with no action.

> 
> 320 [15]
> 
> Insert proposed text but remove examples and references to
> HTTP and SMTP.

If this shrinks the proposal by 2/3 then I think we're done ;-)

> 
> 331 [16]
> 
> Rewrite the sentence: "In general the definition of a message
> exchange pattern" to "MEPs are a type of SOAP features and 
> follow the rules for describing SOAP features in section 
> 3.1.1. A MEP specification:"
> 
> And then remove the first bullet in the four bullet list in
> section 3.3

Noah, can you comment on this as you were at the face to face?

> 
> 334 [6]
> 
> No action. The relationship between feature and MEP is
> explained in both 3.1 and 3.3.

+1 and already closed

> 
> 335 [7]
> 
> No action. As it is an example, I think we are ok.

+1 and already closed

> 
> 352 [8]
> 
> Indicate the infoset properties using some style. I think
> it's confusing to use [name] as it overloads the [reference] 
> mechanism.

This has always been the case and merely follows the convention laid out
in the Infoset spec. I do not want to move away from square brackets.

> 
> 353 [9]
> 
> I agree with Gudge's proposal including renaming section 3.1

+1 and already done and closed.

> 
> 357 [10]
> 
> No action. I prefer DataEncodingUnknown because
> "SOAPEncoding" is used to mean the encoding defined in part 2 
> while this subcode can apply to any encoding.

Oops, we've already made this change.

> 
> 361 [11]
> 
> I agree with not renaming itemType.

+1 and already closed

> 
> 373 [12]
> 
> I agree with Gudge's mail to dist-app [13] that we should not
> require normalization

+1

> 
> Minor Nits
> ----------
> 
> * In the inserted paragraph in section 3.1:
> 
> "The term 'SOAP Module' refers to the set of syntax and
> semantics associated with implementing a particular feature 
> (see 3.1 SOAP Features) as SOAP headers. A Module is 
> described in a Module Specification, which adheres to the 
> following rules. It:"
> 
> It uses the term "SOAP header". I think we should be careful
> and use "SOAP header blocks" as otherwise people get confused 
> as to whether we mean *the* SOAP header or blocks. If you are 
> ok then I can fix this.

I merely mirrored what was in the existing text, which said 'SOAP
header'

> 
> * I don't understand the paragraph in section 3.2:
> 
> "MUST, if* the Module implements a Feature which has already
> been defined elsewhere, clearly refer to that Feature's URI. 
> Note that a Module may EITHER explicitly refer to a separate 
> Feature in this way OR may implicitly define a Feature simply 
> by describing the semantics of the Module."
> 
> Is that a cut&paste error?

Is what a cut and paste error?

> 
> * In section 5.4.5, in the inserted paragraph:
> 
> "The Detail element information item MAY be present in a SOAP
> fault in which case it carries additional information 
> relative to the SOAP fault codes describing the fault (see 
> 5.4.6 SOAP Fault Codes). For example, the Detail element 
> information item might contain information about a message 
> not containing the proper credentials, a timeout, etc. The 
> presence of the Detail element information item has no 
> significance as to which parts of the faulty SOAP message 
> were processed."

This text is from your original proposal

> 
> I think the last sentence easily can be misread to say that a
> detail element says nothing about whether parts of the 
> message processing succeeded and parts failed. 

OK

> However, we
> know that a SOAP fault is for the whole message and not parts 
> of the message. What I think we want to say is this:
> 
> "The presence of the Detail element information item has no
> significance as to which parts of the faulty SOAP message 
> failed during processing."

I guess you want to amend your proposal then

Gudge

Received on Monday, 2 September 2002 22:13:59 UTC