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

[Andre Merzky]

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