W3C home > Mailing lists > Public > xmlp-comments@w3.org > August 2002

Re: issue 227

From: <noah_mendelsohn@us.ibm.com>
Date: Tue, 20 Aug 2002 14:09:23 -0400
To: "Mark A. Jones" <jones@research.att.com>
Cc: Mark Baker <distobj@acm.org>, jacek@systinet.com, marc.hadley@sun.com, moreau@crf.canon.fr, "Williams, Stuart" <skw@hplb.hpl.hp.com>, xmlp-comments@w3.org
Message-ID: <OF3D3E828E.7C165262-ON85256C1B.00625EED@lotus.com>

I'm backed up from being out sick, and haven't read this whole thread.  At 
the risk of jumping in without context:

Mark Jones writes:

>> Upon reading Noah's minutes, I think 
>> that Mark (Baker) is probably right 
>> about the interpretation of point 
>> (3) -- "leave web method as a
>> mandatory feature of the http binding". 

Let's be careful.  My interpretation of the WG's decision (with which I 
happen to concur) is:

1) It is not in general prohibitied for a given binding to depend 
mandatorily on a certain feature.  Stated more verbosely:  it is note 
required that a binding specify how that binding might be used if the 
information required by some particular feature(s) is not supplied, and 
thus if the processing mandated by that feature is not performed. 

2) In particular, the HTTP binding will continue to depend in this manner 
on the WebMethod feature.  Thus, the HTTP binding spec mandates that the 
rules of webMethod MUST be follwed, and those in turn call for 
specification of a partcular method property.

>> It certainly implies that 
>> implementations must code for the feature.

3)  Here's where we have to be careful.  These are all abstractions in any 
case, and nothing at any level of the properties presentation (I.e. 
feature-based or otherwise) says how to structure your code or APIs.   In 
your favorite Java/PERL/whatever implementation you can indeed infer 
methods in a wide variety of ways.   You must merely be capable of 
answering the question when asked:  did your implementation behave as if 
there was a known, stable value for the web method, and if so, to it 
behave in a manner conformant with the feature spec.

I believe that all this was settled quite crisply and finally at the F2F. 
Where is the remaining ambuguity or discomfort (obviously I understand 
some of the discomfort, as the F2F decision was clearly a compromise in 
the view of some, but I thought it was settled.)

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







"Mark A. Jones" <jones@research.att.com>
Sent by: xmlp-comments-request@w3.org
08/20/2002 01:37 PM

 
        To:     Mark Baker <distobj@acm.org>
        cc:     "Williams, Stuart" <skw@hplb.hpl.hp.com>, xmlp-comments@w3.org, 
jacek@systinet.com, marc.hadley@sun.com, moreau@crf.canon.fr, (bcc: Noah 
Mendelsohn/Cambridge/IBM)
        Subject:        Re: issue 227



Upon reading Noah's minutes, I think that Mark (Baker) is probably
right about the interpretation of point (3) -- "leave web method as a
mandatory feature of the http binding".  It certainly implies that 
implementations must code for the feature.  The discussion as Mark 
recalls it also implies that it must be used, i.e., that applications 
must supply a value for it.  There was a following bit of discourse 
(also captured in the minutes) which clarified that a feature spec could 
mandate a default value -- such a feature would obviously be optional in 
use:
   [MarkB] does "must supply a value" imply a default?
   [mitrepaul] My reading is no.  Unless we say that.
   [scribenrm] Clarification:   mandatory in the sense that bindings can
     mandate that applications (nodes, whatever) must conform to the
     features spec, supply values for properties per the features spec,
     etc.
   [MarkB] ah, ok, *application* must supply ... that's ok
   [scribenrm] DF:  answer to MarkB...only if the feature spec says the
     value defaults.

I took that last comment to mean that the feature being discussed (web 
method) was such a feature -- mandatory in implementation, optional in 
use, but defaulting (in this regard it would 'manditorily' get a value). 
  But I confess that I wasn't as attuned to the nuances as Mark was in 
this discussion at the time.

--mark

Mark Jones
AT&T

Mark Baker wrote:

> Hi Stuart,
> 
> On Tue, Aug 20, 2002 at 10:43:57AM +0100, Williams, Stuart wrote:
> 
>>Hi Mark,
>>
>>Well it would appear that the resolution recorded in xmlp-comments [1] 
may
>>not fully reflect what the WG appears to have agreed at the F2F.
>>
> 
> Agreed.  I guess the ball's in your court in terms of deciding what you
> want to do next; just patch the resolution based on what was agreed at
> the f2f (though I don't believe that the minutes haven't yet been
> approved), or reopen the issue.
> 
> 
>>As you might expect I am happy with Mark's clarification, although I 
imagine
>>that you are not ;-).
>>
> 
> 8-)
> 
> 
>>If we examine the other case... ie.. mandatory applies to use of the
>>feature... I have two remarks:
>>
>>1) IMO the case for making use 'mandatory' has not been made.
>>
> 
> I think it was made, in part, during the discussion about inferring the
> method from the MEP; that not only can the method not be inferred, but
> that the application should specify it explicitly.  That's my
> recollection anyhow.  I agree that probably wasn't spelled out as an
> explicit position by anyone.
> 
> 
>>2) It is impossible for an external observer to assess compliance with a
>>MUST use constraint on the Web Method feature - so the constraint is 
largely
>>meaningless.
>>
> 
> I think it's quite testable at design time, just not at run time; just
> write some code that uses the APIs provided by the library, and see if
> the library lets you send a message without specifying a method; if it
> does, it's not compliant.
> 
> MB
> 


-- 
Mark A. Jones
AT&T Labs
Shannon Laboratory
Room 2A-02
180 Park Ave.
Florham Park, NJ  07932-0971

email: jones@research.att.com
phone: (973) 360-8326
   fax: (973) 236-6453
Received on Tuesday, 20 August 2002 14:13:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:27 GMT