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