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

Steve Loughran steve_loughran at hpl.hp.com
Tue May 9 10:11:43 CDT 2006


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





More information about the ogsa-wg mailing list