Oops, we forgot to standardize on a method dispatch mechanism! *groan*
(link) [del.icio.us/distobj]

That’s how you do it, more or less. I wonder if hierarchy isn’t used properly though, i.e. having “tag” as subordinate to “item”; if you DELETE the item, does the tag go too? Maybe it does.
(link) [del.icio.us/distobj]

Phil Windley summarizes
a point by Dion Hinchecliffe;

I spoke with Dion yesterday and he talked to me about governance mistakes he sees clients making. The number one problem is something he called the “tyranny of the `MUST understand’ flag.” You get a SOAP-based Web service loaded up with WS-* header elements all tagged ‘MUST understand’ and you end up with something every-bit as much a central command and control structure as if you’d just reintroduced the mainframe. No one can do anything unless they’re using the same toolset.

I think I understand the issue here, but I think there’s more to it than
you might extract from that paragraph.

First off, mandatory extension mechanisms like
are a Good Thing, because it makes messages more self-descriptive; if a message
is extended in such a way that older processors can’t accurately interpret the
message, then you need it to save those processors from processing a message
which they can’t process.

That said though, there needs to be recognition that there’s a fairly high
cost of deployment of these kinds of extensions because each one that’s defined
basically bifurcates the space of interoperable agents (you know, just like
deploying a new service interface does … but that’s another issue 8-).

And that’s where I agree with Dion. If you find yourself using mustUnderstand
in more than a handful of your interactions, chances are that you’ve messed up
somewhere, likely by failing to account for sufficient extensibility in previous
versions. In fact, I’d even extrapolate from that to suggest that if you’re using
mustUnderstand in version 1.0 of your system, and that system is closed (i.e. behind
a firewall, or otherwise not interacting with pre-existing software), you’ve
definitely screwed up.

Speaking of which… Perhaps the worst offender in this regard is
because it effectively mandates the use of at least one mandatory extension in every
message; wsa:To. Well, technically it doesn’t require that it be tagged as
mandatory, but I think it’s pretty obvious that if a recipient didn’t understand
where the message was addressed, that all hell would break lose if it tried to process
it. So, if you use WS-Addressing, then all of your messages are prima facie
unprocessable by all existing SOAP software
. Oopsie!

“The whole point of Ajax is to make the web easier to use. Not to move us back in time.” Amen to that, and a big “ouch” to live.com.
(link) [del.icio.us/distobj]

Oh joy! Something to look forward to on Manly beach when I’m there in January!
(link) [del.icio.us/distobj]

Now hiring!
(link) [del.icio.us/distobj]

“It doesn’t put itself on the line, so it isn’t science”. Most succinct rebuttal to ID I’ve heard.
(link) [del.icio.us/distobj]

a common mistake is to take a layered design as a requirement for a correspondingly layered implementation

Gaining Efficiency in Transport Services by Appropriate Design and Implementation Choices,
by Watson and Mamrak, ACM TOCS, 1987.

Compare and

Specifically, Internet based efforts (including the Web, of course) always start with an interface constraint. This is simply for the reason that they’re (usually) always focused on a single task – for example, email exchange, mail folder access and synchronization, file transfer – and pay little to no attention to what it means to define interoperability between those applications, since that’s tangential to their primary objective. A consequence of this approach is that there becomes little value in using a common sub-layer-7 protocol (like BEEP, IIOP, or how most people use SOAP).

“Absolutes do not apply”. Never? 8-)
(link) [del.icio.us/distobj]

The Brain Gain continues …
(link) [del.icio.us/distobj]