[ogsa-wg] Thoughts on extensions mechanisms for the HPC profile work

[Marvin Theimer]

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