RE: issue 227

I agree with Stuart 100% on this as to both the longer term history and 
the specifics of the resolution of 227.  I was there at the F2F (I think 
Mark Baker was on the phone, not sure), and I happen to have written the 
minutes in question.

Mark Baker asks:

>> How do you reconcile that with the proposal;
...
>> i.e. that applications must supply a 
>> value for the ] property...and to make 
>> sure the spec is clear on that point.

>> specifically the "applications must supply a value" part?

The minutes, as you know, are unedited at this time and are written 
stream-of-consciousness by the scribe.  Their purpose is to capture enough 
that accurate minutes can be written and to ensure that issues are 
resolved in the intended manner.  Specifically, the way I reconcile the 
situation is this:  as scribe and as someone who is well familiar with the 
binding framework I took it is an absolute given that any behavior we were 
describing was implicitly within the assumptions we've been making right 
along, which are exactly as Stuart describes them.  So, when I wrote the 
above, I meant what he meant in his note yesterday. 

Specifically, "applications must supply a value" was the scribe's 
shorthand for what it always means in the binding framework for a property 
to have a value:  I.e., the node must be capable, in some implementation 
defined means of answering the question "what is the value of the method 
property." 

We never, never talk about API's or internal structure of the node. 
Indeed, there's nothing that says that any other property is supplied by 
the application in any sense other than what I've just said.  Consider the 
envelope infoset itself.  We don't say where it comes from.  We don't 
describe even roughly an API that would lead to it's existence.   The 
envelope can be burned in ROM.  It can live always at location 100 in main 
memory.   You can do an (admittedly unlikely and probably undesireable) 
implementation in which all your TCP code is scrambled in with all your 
application code, which is scrambled with all your SOAP code, HTTP binding 
code, IP code, etc., and there is no API between layers at all.  SOAP is 
silent on this, just as TCP/IP (a clearly layered protocol) is silent on 
how the actual implementations are layered (and there has been wonderful 
published work going back over 20 years showing that the unlayered 
implementations are often superior for performance.) 

So:  we don't say where the envelope comes from;  we don't say where the 
destination URI comes from; we don't say where the webMethod comes from. 
Similarly, the TCP specification doesn't say where the stream to be sent 
comes from, but that spec does require that you in some way you know have 
a stream to send.  Similarly, our HTTP binding cannot be used unless your 
implementation can answer the questions:  what is the destination URI, 
what is the envelope infoset, what is the webMethod.  How an 
implementation represents or passes around those values between its 
internal layers is way beyond our spec.

====

One other thing:  there's been some discussion of openning new issues, 
etc.  I strongly disagree.  The workgroup has passed (unless I 
misunderstand the W3C process) the time at which we in the WG get to open 
new issues, unless of course there is something so truly broken that the 
system just won't run, the spec lies outright, etc.  Where we are on this 
is:  issue 227 was raised.  The workgroup voted to close it and we have 
unedited minutes of the scribe, followed by proposed resolution text.  The 
original resolution text did not make members of the wg and (I believe) 
the originator completely happy, so we've spent some time tuning it up.  I 
think where we are is that we now have a clearer statement of what the WG 
decided (or what I'm confident the wg decided), and agreement from the 
originator that it's OK. 

Mark Baker has raised some questions abouyt the scribes minuntes of the 
F2F, and also about the implications for APIs.   Stuart and I have weighed 
in strongly that nothing in the bindings, binding frameworks or http 
binding in particular has ever attempted to deal with API level issues, 
and I don't think that's a debate we should be openning now.  As I have 
made clear, the scribe intended nothing otherwise in the minutes, and I 
apologize for any confusion.

So my personal position is:  we raised an issue, we did a reasonably 
careful job of resolving it and some of those involved such as Stuart (and 
Marc Hadley, I suspect) have been kind enough to go along with a 
resolution that I suspect is not their first choice.  I think we have text 
that captures the resolution.   I would strongly urge us not to use this 
is an opportunity to look for more things to debate and resolve.  Unless 
I'm mis-remembering, the WG has specifically voted to pass that point in 
the process and to devote its efforts to reflecting in a new draft the 
resolutions that we have agreed.  Of course, this is just my personal view 
of where we stand.  I'd like to update the resolution text of 227 and move 
on.  Thank you.

------------------------------------------------------------------
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>
08/22/2002 05:33 AM

 
        To:     "'Mark Baker'" <distobj@acm.org>, noah_mendelsohn@us.ibm.com
        cc:     Henrik Frystyk Nielsen <henrikn@microsoft.com>, jacek@systinet.com, 
jones@research.att.com, marc.hadley@sun.com, moreau@crf.canon.fr, 
"Williams, Stuart" <skw@hplb.hpl.hp.com>, xmlp-comments@w3.org
        Subject:        RE: issue 227


Mark,

To the best of my knowledge and throughout my involvement in the TBTF and
the WG it has always been clear (at least to me) that the binding
framework/SOAP extensibility model along with the concepts of features,
properties, property containers (message exchange context) modules and
bindings are descriptive tools to enable the structuring and re-use of
components parts of a specification. At no time (to my recollection) has 
it
ever been the intention that the structure of the description (partitioned
into features specs, binding specs, and module specs) be prescriptive on 
the
structure of an implementation. The thing that it does make sense to be
precriptive about is the externally observable behaviour of 
implementations
that claim conform to the specifications - ie. they claim to exhibit the
behaviour that the specifications require.

The position you appear to be taking is that the WGs resolution of 227 
does
indeed place requirements on the structure of an implementation. I may 
have
miss read that - in which case I'm sure you will correct me. But if that 
is
your position, then I believe that it is on the other side of a line that
the TBTF and the WG took some care not to cross.

To summarise:

The binding framework (features, properties, message exchange contexts) in
particular is about structuring the behavioural description embodied in a
binding specification. It is *not* about constraining the structure of an
implementation. It may be convenient as a means to meet the behavioural
requirements of a binding specification to structure an implementation 
along
the lines of the framework based specification... but it is not (IMO) a
requirement to do so.

So suggest otherwise... is what I characterised as attempting "...to cease
more ground...." in an earlier response... and would be a *big* change in
the WG's philosophy with respect to the framework.

Best regards

Stuart
--

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: 22 August 2002 00:20
> To: noah_mendelsohn@us.ibm.com
> Cc: Henrik Frystyk Nielsen; jacek@systinet.com; 
> jones@research.att.com;
> marc.hadley@sun.com; moreau@crf.canon.fr; skw@hplb.hpl.hp.com;
> xmlp-comments@w3.org
> Subject: Re: issue 227
> 
> 
> Hi Noah,
> 
> On Wed, Aug 21, 2002 at 06:15:14PM -0400, 
> noah_mendelsohn@us.ibm.com wrote:
> > * Issue 227 in particular questions such mandatory use of the 
webMethod 
> > feature by the HTTP binding.  The WG has voted to make no change in 
this

> > mandatory use of the webMethod feature by the http binding.  The HTTP 
> > binding continues to mandate that a sending node determine the 
webMethod

> > (e.g. POST, GET) to be used when transmitting a non-Response message. 
> > (Note that the entire property-based binding framework is abstract: at
no 
> > point does the HTTP binding attempt to describe a particular API or 
> > implementation structure, so this resolution says nothing about 
whether 
> > method names such as GET would be supplied explicitly or otherwise on
some 
> > particular API;
> 
> How do you reconcile that with the proposal;
> 
> ] [scribenrm] DF: Proposal...(1) we accept that bindings can specify
> ] that features are mandatory (2) we sweep the spec to ensure that's
> ] clear (3) leave web method as a mandatory feature of the http
> ] binding...i.e. that applications must supply a value for the
> ] property...and to make sure the spec is clear on that point.
> 
> specifically the "applications must supply a value" part?
> 
> Or, from the LC WD;
> 
> "Bindings to HTTP or such other protocols SHOULD use the Web Method
> Specification Feature to give applications control over the 
> Web methods
> to be used when sending a SOAP message."
>  -- http://www.w3.org/TR/soap12-part2/#WebMethodFeature
> 
> What I extract from your proposal is that it's ok for the SOAP library
> to supply the value without direction from the application. 
> This seems
> to be a significant change from the current WD.  I agree that 
> there are
> valid cases where the library can supply the value, such as if the API
> it exposes can suitably represent the semantics of the methods to the
> developer; e.g.  "o < foo" triggers GET, "o > foo" triggers PUT,
> "o >> foo" triggers POST, etc..  But I'm concerned that SOAP
> implementers will think that by saying nothing about this, that we're
> giving the thumbs up to doing things like inferring the 
> method from the
> MEP, or other information which has nothing to do with the method.
> 
> If you like that reasoning, I can write it up as a proposal.
> 
> >  it merely mandates that the sending node determine the 
> > method in some implementation specific manner, and it 
> declines to supply 
> > any standard way of inferring the method from other 
> information provided 
> > with the message to be transmitted."
> 
> Wouldn't a SOAP 1.1 node meet that criteria?
> 
> MB
> -- 
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@acm.org
> http://www.markbaker.ca        http://www.idokorro.com
>

Received on Thursday, 22 August 2002 10:40:21 UTC