RE: issue 227

Hi Mark,

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: 21 August 2002 01:03
> To: noah_mendelsohn@us.ibm.com
> Cc: Mark A. Jones; Mark Baker; jacek@systinet.com; 
> marc.hadley@sun.com;
> moreau@crf.canon.fr; Williams, Stuart; xmlp-comments@w3.org
> Subject: Re: issue 227
> 
> On Tue, Aug 20, 2002 at 02:09:23PM -0400, 
> noah_mendelsohn@us.ibm.com wrote:
> > 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.
> 
> There's a middle ground here that I have in mind, though I haven't
> talked about it because it would complicate things to propose it.
> Suffice it to say that I prefer that we err on the side of caution, and
> require that the method be explicitly set by the application, compared
> to the alternative on the table of providing no guidance and saying that
> it's ok to hide the method from the application developer by providing a
> default, inferring it from MEP, etc..
> 
> If it would help for me to describe my middle ground 
> approach, then I'd be happy to do so.

I think you seek to cease much more ground than you have 'won'. In doing so
I think you risk a fragile peace.

I have twice stated that I can let the matter rest with the WG's resolution
and the reasons why (lest anyone should infer that I agree with the WGs
reasons for resolving the issue the way that that they have). 

But we do not have to agree on that logic in order to let the matter rest,
only that the resolution (as stated in xmlp-comments and clarified in this
thread) is one that we can live with.

> >   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.)
> 
> I thought it was settled too; the application must specify a Web method,
> as the proposal clearly stated.  8-/  Are there varying interpretations
> of "application" perhaps?  I guess I don't see where the disconnect is in
> interpreting the proposal that we voted to adopt, although I do see the
> problem with the proposed resolution text.

...and the proposed resolution text is what started this thread... and the
request for clarification came from me, the originator of the issue who was
not as it happens Cc'd on the resolution. As to disconnects... there are
folks who weren't at the meeting who have an interest in the resolution, and
who perhaps have a reasonable expectation that the resolution posted to
xmlp-comments is a complete statement of the resolution - without having to
trawl through a bunch of unreferenced (by the resolution) material.

> Thanks.
> 
> MB
> -- 
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@acm.org
> http://www.markbaker.ca        http://www.idokorro.com


Regards

Stuart

Received on Wednesday, 21 August 2002 05:24:07 UTC