FW: Proposals for remaining editorial spec issues

Forwarding...

-----Original Message-----
From: Henrik Frystyk Nielsen 
Sent: Sunday, August 25, 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.

253 [1]

No action. XML base (and implicitly RFC 2396) does define the scope of a
base URI.

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

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

283 [4]

Ok with Gudge's proposal: Add enc:DuplicateID and modify prose
accordingly 

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.

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. 

320 [15]

Insert proposed text but remove examples and references to HTTP and
SMTP.

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

334 [6]

No action. The relationship between feature and MEP is explained in both
3.1 and 3.3.

335 [7]

No action. As it is an example, I think we are ok.

352 [8]

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

353 [9]

I agree with Gudge's proposal including renaming section 3.1

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.

361 [11]

I agree with not renaming itemType.

373 [12]

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

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

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

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

Henrik

[0] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x227
[1] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x253
[2] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x279
[3] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x280
[4] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x283
[5] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x289
[6] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x334
[7] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x335
[8] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x352
[9] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x353
[10] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x357
[11] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x361
[12] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x373
[13] http://lists.w3.org/Archives/Public/xml-dist-app/2002Aug/0028.html
[14] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x284
[15] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x320
[16] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x331

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