Issue accepted.

As usual, Roy nailed it;

seems the direction of all ws specs is to be binding neutral, but no statement that a given binding is required so entirely separate architectures all described as web services
A Web services developers gives REST a try
(link) [del.icio.us/distobj]
“But the low overhead also means that REST doesn’t include built-in security and reliability, so it’s not well-suited for enterprise use, particularly between business partners or for e-commerce.”. Sigh.
(link) [del.icio.us/distobj]

Bill deHora comments on Mnot’s latest, saying this about something he heard somebody say;

He has a nice comment near the end on how having less options can be a good thing.

I didn’t hear the interview, but yah, absolutely. It’s arguably the fundamental theorem of design (all design, not just software design). But we should be careful to clarify that it’s “less options” of form, not function. That is, by constraining form we’re only limiting how solutions are developed, not what those solutions are capable of doing. I think that if the point was better understood by Web services proponents, we would have made progress towards decisions like this one – which constrains form by virtue of requiring all identifying information in a single data element, without constraining function – a long time ago (and arguably never have bothered with Web services at all).

I’ve been heard to explain my transition from being a CORBA proponent to a Web proponent in these same terms; that I in a gestalt moment in 1998, I realized that the Web was, more or less, “distributed objects” (“identifiable things on a network that you can chuck messages at”) with some additional constraints on form.

And that’s the good news! 8-)
(link) [del.icio.us/distobj]
Good question. Most WS proponents want to distance themselves from CORBA, yet the architectures are eerily similar.
(link) [del.icio.us/distobj]

Massive kudos to the WS-Addressing WG (in particular Dave Orchard) for agreeing to drop reference properties from the WS-Addressing specification!! This addresses the most major(!) concern I had with the specification, and leaves EPRs as a means for bundling a URI with some state; cookies meet XML, as it were.

This decision means that a by-the-book EPR will contain only a single resource-identifying data element; a URI. In other words, the WG is adopting the REST constraint of a single resource-identifying data element. More concretely, it means that Web services will actually be encouraging the use of URIs for identifying things, rather than the old practice of using them as dispatch points behind which countless resources were hidden. This is HUGE, because in my experience, once you’ve adopted URIs, the use of http URIs and therefore HTTP (buh bye protocol independence) just naturally follow due to the massive network effects of the Web. The use of “hypermedia as the engine of application state” is the next obvious constraint for adoption after that.

It’s possible that with this decision, Web services might have just stepped inside the Web’s Schwarzschild Radius. Stay tuned.

“So any signs that “tag spam” has started yet?” Yup, I spotted one last October, IIRC – a single posting with a bazillion tags. Reported it, and it was removed. Haven’t seen it since.
(link) [del.icio.us/distobj]

Egads, I didn’t think I was that nerdy;

I am nerdier than 98% of all people. Are you nerdier? Click here to find out!

It probably has a lot to do with my uncanny ability to recall the periodic table.

That’s my story, and I’m sticking to it.

Update; I may be a nerd, but at least I’m not (too) weird;

What is your weird quotient? Click to find out!

Of all the weird test takers:

91% are more weird,
5% are just as weird, and
4% are more normal than you!

Since when was layer 6 the application layer? Sarvega/DataPower (and Web services infrastructure general) are one layer too low. Cisco should be looking at KnowNow
(link) [del.icio.us/distobj]