W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2002

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

From: <noah_mendelsohn@us.ibm.com>
Date: Wed, 24 Jul 2002 19:26:41 -0400
To: "Williams, Stuart" <skw@hplb.hpl.hp.com>
Cc: "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>
Message-ID: <OF704730D8.A0A45325-ON85256C00.007FA48E@lotus.com>

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

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.

What do you think?

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







"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 Wednesday, 24 July 2002 19:27:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:10 GMT