[saga-rg] Fwd (theimer at microsoft.com): RE: [ogsa-wg] Thoughts on extensions mechanisms for the HPC profile work

[Hartmut Kaiser]

Sounds sensible to me.

Regards Hartmut 

> -----Original Message-----
> From: owner-saga-rg at ggf.org [mailto:owner-saga-rg at ggf.org] On 
> Behalf Of Andre Merzky
> Sent: Wednesday, May 17, 2006 6:34 AM
> To: SAGA RG
> Subject: [saga-rg] Fwd (theimer at microsoft.com): RE: [ogsa-wg] 
> Thoughts on extensions mechanisms for the HPC profile work
> 
> Hi SAGA, 
> 
> see below a mail quited from Marvin Theimer, which went to 
> the OGSA list.  I think his points about implementation of 
> optional features are very valid ones, and I would like to 
> add a similar statement to the spec, like: "A saga object or 
> method MUST be implemented with exactly the semantics 
> specified, or not at all."
> 
> Any thoughts on that?
> 
> Cheers, Andre.
> 
> 
> ----- Forwarded message from Marvin Theimer 
> <theimer at microsoft.com> -----
> 
> > Subject: RE: [ogsa-wg] Thoughts on extensions mechanisms 
> for the HPC 
> > profile work
> > Date: Thu, 11 May 2006 18:16:01 -0700
> > From: Marvin Theimer <theimer at microsoft.com>
> > To: Steve Loughran <steve_loughran at hpl.hp.com>, ogsa-wg at ggf.org
> > 
> > Hi;
> > 
> > I agree with you that we should try to keep to as simple a means of 
> > specifying the concept of "must understand" or "may ignore" 
> as possible.
> > I haven't looked at the difference between how soap1.1 and 
> soap1.2 do 
> > things and will go off and do my homework.
> > 
> > One thing that I believe is happening in this conversation 
> is that two 
> > separable issues are being convolved together.  One issue 
> is whether 
> > or not to allow optional feature specifications.  The other 
> has to do 
> > with the main concern that I heard in your email, namely 
> that "optional"
> > features are often ill-defined in terms of their semantics. 
>  I would 
> > argue that the semantics of optional features need to be precisely 
> > defined -- including what it means if the feature is optional.  I 
> > would argue that ANY feature that isn't precisely defined in a spec 
> > has the potential to cause interop problems.  So I would argue that 
> > "must understand" features must be implemented precisely 
> and completely.
> > Alternatively, "may ignore" features must be either completely and 
> > precisely implemented or not at all (meaning the semantics provided 
> > must be those if the feature had not been mentioned).
> > 
> > Marvin.
> > 
> > 
> > -----Original Message-----
> > From: owner-ogsa-wg at ggf.org [mailto:owner-ogsa-wg at ggf.org] 
> On Behalf 
> > Of Steve Loughran
> > Sent: Tuesday, May 09, 2006 8:12 AM
> > To: ogsa-wg at ggf.org
> > Subject: Re: [ogsa-wg] Thoughts on extensions mechanisms 
> for the HPC 
> > profile work
> > 
> > Marvin Theimer wrote:
> > > Hi;
> > > 
> > > The beauty of a "may ignore" flag is that it can be ignored. :-)  
> > > So, whereas I side with Donal in believing that complex optional 
> > > resource descriptions rarely work well, I side with Karl in 
> > > believing that the flag should be available at the protocol level 
> > > (as an extension case since I'm trying to be hard-nosed about not 
> > > letting anything creep
> > into
> > > the base case that isn't absolutely necessary for minimal 
> interop).  
> > > 
> > > It's worth noting that the concept of "optionally understood"
> > parameters
> > > is something that many consider to be one of the bigger success
> > stories
> > > of the way the Web works (as compared to Web services).
> > > 
> > 
> >  > Marvin.
> >  >
> > 
> > 
> > Sometimes. But then there is the way that you have to comment out 
> > stuff in script tags in case a legacy browser renders your 
> javascript, 
> > which strikes me as a failure mode of the HTML extension system:
> > 
> > <script><!-- fun something() { .. } --></script>
> > 
> > 
> > In SOAP1.1 the mustUnderstand logic is simple and pretty 
> much all you 
> > need. SOAP1.2's MU logic is way more convoluted, and that 
> makes it a 
> > dog
> > 
> > to test -which, in a TDD process, means a dog to implement, 
> and will 
> > inevitably a source of problems for years to come.
> > 
> > One issue with mustUnderstand logic, is what does 
> "understand" mean? 
> > Does it mean "recognise", or does it mean "process in 100% 
> compliance 
> > with the official specification of what this soap header required".
> > Axis1.1 shipped with the check for all headers being 
> understood taking 
> > place *after* the message was delivered. While following 
> the letter of 
> > SOAP1.1, and passing the limited (stateless) tests of 
> SOAPBuilders, it 
> > violated the spirit of the spec quite blatantly.
> > 
> > It's testing those optional bits that really hurts. Unless 
> the clients 
> > implement all possible bits of optional behaviour, you cannot tests 
> > that
> > 
> > the endpoints implement it properly. This essentially makes it 
> > impossible to make any declaration about the quality of 
> implementation 
> > of any optional part of a spec -you have to just hope for the best.
> > 
> > summary: whenever you mark something as optional, you create an 
> > interop problem.
> > 
> > -Steve
> 
> ----- End forwarded message -----
> 
> --
> "So much time, so little to do..."  -- Garfield
>