W3C home > Mailing lists > Public > www-archive@w3.org > September 2002

FW: Proposals for remaining editorial spec issues

From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
Date: Mon, 2 Sep 2002 19:13:26 -0700
Message-ID: <79107D208BA38C45A4E45F62673A434D08618272@red-msg-07.redmond.corp.microsoft.com>
To: <www-archive@w3.org>


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

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

Because of discussion at the f2f?

>> 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 ;-)

I am hoping that is the case :)

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


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

You mean that it's too late, that I am being silly, or... ;)

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

Hmm, I thought we went through the spec before to fix these.

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

I can make no sense of the first sentence :(

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

Geez :(

>> 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."
>I guess you want to amend your proposal then



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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:31:53 UTC