RE: LC #220 (was RE: Raw minutes of 10 July 2002)

Hi Noah,

> -----Original Message-----
> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com]
> Sent: 25 July 2002 00:27
> To: Williams, Stuart
> Cc: 'xml-dist-app@w3.org'
> Subject: RE: LC #220 (was RE: Raw minutes of 10 July 2002)
> 
> 
> Overall looks good.  How about:
> 
> <stuartProposal>
> A binding specification MUST NOT specify any variation to
> the SOAP processing model (see 2. SOAP Processing Model).
> </stuartProposal>
>
> I'm not 100% comfortable with this, as it is a bit ambiguous. 
>  Bindings can indeed specify variations in the sense of choosing a 
> flavor from among the many legal ones (for example, a binding might be
involved in 
> determining the SOAP roles to be played).  What's not allowed is to vary 
> the model itself, I.e. to do something inconsistent with the model. 

Ok.. the meaning I had intended is, I believe the meaning that you are
asking for - and I can see that 'variation' could give scope for
ambiguity... but the subject of the final clause is "the SOAP processing
model (ref)". 

Other alternatives to "specify any variation to":

"vary"
"alter" or "specify any alteration to"
"modify" or ...

> What about something along the lines of:
> <slightRevision>
> Processing  processing of SOAP envelopes MUST in all cases be 
> as specified in 2. SOAP Processing Model;  the constaints of 2. SOAP 
> Processing Model MUST NOT be overridden by binding specifications.
> </slightRevision>

I'd be ok with that... I was trying to make a compact single sentence.
Actually, your second clause alone seems to have it:

"[T]he constaints of 2. SOAP Processing Model MUST NOT be overridden by
binding specifications."

Although I'm tempted to remove "constraints of" leaving:

"The 2. SOAP Processing Model MUST NOT be overridden by binding
specifications."

or maybe

"The processing of SOAP envelopes in accordance with the 2. SOAP Processing
Model MUST NOT be overridden by binding specifications."

[Might want to clear that this applies only to the 'primary SOAP message' in
a compound SOAP structure, but that concept is not present in the part1/2
specs.]

> Actually, I find MUST NOT to be somewhat inappropriate.  In terms of plain

> English I would prefer "cannot".  MUST NOT seems to suggest that this is 
> something that you might want to do, but aren't allowed to.  "Cannot" 
> suggests:  it wouldn't make sense to do this;  if you tried, the result 
> wouldn't be SOAP.  Then again, I don't think a lowercase "cannot" would 
> have any normative force, hence the suggestion of MUST NOT.

Yup... MUST NOT does feel ugly here. I did experiment with the more
matter-of-fact "does not" but that really places no imperative a binding
specification. The MUST NOT is a requirement on a binding specification...
and I think it does have interop implications... so the capitalised
imperative is appropriate, but yes I would have preferred to find away
around using RFC2116 imperatives.

> What do you think?

I think we're very close to closure on this one. I think we know what we
want to say... the remainder is editorial tweaking (I think).

> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------

Thanks,

Stuart
---------------------------------------------------------------------
> 
> 
> "Williams, Stuart" <skw@hplb.hpl.hp.com>
> Sent by: xml-dist-app-request@w3.org
> 07/24/2002 05:46 PM
> 
>  
>         To:     "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>
>         cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
>         Subject:        RE: LC #220 (was RE: Raw minutes of 
> 10 July 2002)
> 
> 
> 
> During discussion of this issue on today's telcon I picked up 
> an action 
> item
> to propose some rewording of the two extract at [1] and [2] below.
> 
> Proposed insertions highlighted with >>...<< and a 
> <strikeout> around the
> spliting of a long sentence into to.
> 
> [1] http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#soapfeature
> 2nd to last sentence of last paragraph states:
> 
> <original>
> A binding specification that expresses such features external 
> to the SOAP
> envelope needs to define its own processing rules to which a 
> SOAP node is
> expected to conform (for example, describing what information 
> is passed
> along with the SOAP message as it leaves the intermediary).
> </original>
> 
> <proposal>
> A binding specification that expresses such features external 
> to the SOAP
> envelope needs to define its own processing rules >>for those 
> externally
> expressed features.<< <strikeout>to which a</stikeout> >>A<< 
> SOAP node is
> expected to conform >>to these processing rules<< (for 
> example, describing
> what information is passed along with the SOAP message as it 
> leaves the
> intermediary). >>A binding specification MUST NOT specify any 
> variation to
> the SOAP processing model (see 2. SOAP Processing Model).<<
> </proposal>
> 
> [I'm not entirely convinced that we need the last insert forbidding a
> binding specifying a variation of SOAP processing. Or maybe I have not
> caught what was suggested on the call correctly.]
> 
> 
> [2] 
> http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#transpbindframew
> Last paragraph states:
> <original>
> A binding does not provide a separate processing model and does not
> constitute a SOAP node by itself. Rather a SOAP binding is an 
> integral 
> part
> of a SOAP node (see 2. SOAP Processing Model).
> </original>
> 
> <proposal>
> A binding does not provide a separate processing model >>for the SOAP
> Envelope<< and does not constitute a SOAP node by itself. 
> Rather a SOAP
> binding is an integral part of a SOAP node (see 2. SOAP 
> Processing Model).
> </proposal>
> 
> The first suggestion [1] might benefit form a little more tweaking...
> 
> Best regards
> 
> Stuart
> --
> > -----Original Message-----
> > From: Williams, Stuart 
> > Sent: 11 July 2002 12:30
> > To: 'Jean-Jacques Moreau'
> > Cc: w3c-xml-protocol-wg@w3.org
> > Subject: LC #220 (was RE: Raw minutes of 10 July 2002)
> > 
> > 
> > > 220
> > > 
> > > DavidO: Don't understand the issue.
> > > MarcH: Agree.
> > > DavidO: Wait for Stuart.
> > > 
> > > Postponed. Wait for Stuart.
> > 
> > Another comment arising from a pre LC review.
> > 
> > Simply stated: One part of the document [1] states that a 
> > binding specification does "define its own processing rules 
> > [for features expressed external to the SOAP envelope] to 
> > which a SOAP nodes is expected to conform."; While another 
> > part of the document [2] states that "a binding does *not* 
> > provide a separate processing model...".
> > 
> > Taken together, the meaning of [1] and [2] is at best not 
> > clear, and at worst contradictory. There may be subtle 
> > differences the use of terms like "processing rules" and 
> > "processing model".
> > 
> > I don't have a fix to offer, because I know what the text is 
> > trying to tell me.
> > 
> > Regards
> > 
> > Stuart
> > --
> > [1] http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#soapfeature
> > 2nd to last sentence of last paragraph states:
> > "A binding specification that expresses such features 
> > external to the SOAP envelope needs to define its own 
> > processing rules to which a SOAP node is expected to conform 
> > (for example, describing what information is passed along 
> > with the SOAP message as it leaves the intermediary)."
> > 
> > [2] 
> http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#transpbindframew
> Last paragraph states:
> "A binding does not provide a separate processing model and does not
> constitute a SOAP node by itself. Rather a SOAP binding is an 
> integral 
> part
> of a SOAP node (see 2. SOAP Processing Model)."
> 
> 
> 
>

Received on Thursday, 25 July 2002 05:40:39 UTC