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"
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 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