Sounds sensible to me. Regards Hartmut
-----Original Message----- From: owner-saga-rg@ggf.org [mailto:owner-saga-rg@ggf.org] On Behalf Of Andre Merzky Sent: Wednesday, May 17, 2006 6:34 AM To: SAGA RG Subject: [saga-rg] Fwd (theimer@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@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@microsoft.com> To: Steve Loughran <steve_loughran@hpl.hp.com>, ogsa-wg@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@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Steve Loughran Sent: Tuesday, May 09, 2006 8:12 AM To: ogsa-wg@ggf.org Subject: Re: [ogsa-wg] Thoughts on extensions mechanisms for the HPC profile work
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"
Marvin Theimer wrote: 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