Web Things, by Mark Baker

Don Park writes

OASIS is now looking at a lionshare of key specs that will dominate the Internet and intranets in the near future. Compared to them, W3C is looking pretty devastated [with disinterest and hopeless dreams] at this point.

I’ve heard that from a number of people over the past couple of years, but I just don’t see it that way. Yes, certainly the W3C has been taking lots of slack from lots of folks who think that Web services are some wonderful new thing, both inside (from W3C members), and out (press). But there’s much more at play here than that.

The fundamental difference between OASIS and the W3C, is that the W3C exists to maintain and enhance an existing software system, while OASIS does not. OASIS’s approach resembles little more than a random land grab, attempting to stake out territory without any consideration for its inherent value. Take Don’s list of specs, for example; SAML, XACML, Liberty, BPEL4WS. There is effectively no architectural consistency at all between those specs, so the chances of them ever working well together as part of a single system (without considerable effort) are pretty darned low. And that’s without even considering that I don’t think they will see much widespread deployment individually (though SAML and XACML aren’t too bad).

Thinking back over the recent history of influential software standards related organizations such as OMG, IETF, W3C, WAPforum/OMA, etc.. the only other one that I can think of that didn’t have a legacy system or architecture to protect is the Opengroup (though the OSF had DCE). The others all had some means of ensuring architectural consistency. The IETF has the IESG and Areas for constraining work. The OMG created the Architecture Board. The WAPforum had an Architectural Consistency group. And the W3C has Activities, Staff, the Director, and more recently, the TAG.

So if OASIS wants to go the way of the Opengroup, they’re certainly on track.

Mark talks about how he implemented his Dive Into Mark Mobile Edition, and in doing so talks about XHTML Basic, which I co-edited. He’s mostly correct, but there are some points I’d like to respond to.

The “link” element has a extremely low conformance profile; all it means to support it is that you don’t fault when you discover it. Supporting “link” doesn’t mean you have to support CSS.

As for the list of elements which XHTML Basic left out, “b”, “i”, “center”, and “font” aren’t there because XHTML 1.0 – from which XHTML Basic builds – removed them in the “presentation belongs in stylesheets” blitz of 1999. Nested tables were indeed removed based on extensive feedback and wide industry support for doing so, due to the memory consumed during their processing. Though I don’t know for sure, I’m quite confident that AvantGo does not support arbitrarily complex nested tables, which suggests that some form of subset would need to be defined should their solution ever be opened up anyhow.

It is not true that XHTML Basic has to use the application/xhtml+xml media type. In many cases it is appropriate to use “text/html”, though the W3C apparently disagrees with me there; their “XHTML Media Types” note says that it “SHOULD NOT” be used. Whatever. I doubt any text/html processor would have trouble with XHTML Basic, just don’t expect it to be treated as XML or XHTML.

Mark’s conclusion, “As I said, XHTML Basic has no basis in reality. Ignore it.”, for North Americans, probably isn’t too far from the truth. In much of Asia and parts of Europe though, it’s important, and its importance will probably be spreading.

Not that I really care that much. The reason I contributed to its development was because of Sun’s objective that WAP should use commodity protocols rather than wireless specific ones, and we did that. Though WAP 2.0 extended XHTML Basic, I’m confident that in time, those extensions will be ignored and HTML/XHTML will remain in some form, likely richer than XHTML Basic. I look forward to seeing that language documented after the fact; XHTML Basic 3.2 anyone? 8-)

More tail-chasing going on over at the W3C with the chartering of the Web Services Choreography WG. I’m really disappointed that Tim didn’t take this opportunity to speak his mind about the mistakes being made with Web services, especially considering that this working group exists to replace the hypermedia application model, which is pretty darned fundamental to Web architecture.

I guess he knows what he’s doing though. Perhaps he feels he can contain Web services, and prevent them from preventing him from leading the Web to its full potential. I did think that the initial move to accept them into the W3C was an excellent one, as there, they may actually be fixed enough to earn the right to call themselves Web services. Unfortunately, nobody seems to be officially assigned to the task to doing just that, though Hugo and David try to keep things in check, what most people know to be Web services (i.e. putting the method name in the SOAP envelope) is a fundamentally broken style for the Internet, which is a big issue for them to tackle, especially given the mostly neutral positions they’re expected to hold as team contacts (not officially, but in practice it’s hard for them to hold strong opinions). That’s why I’ve been doing it.

A nice surprise turned up in my IETF mailbox this yesterday, Applying WebDAV to Network Configuration Management Problems.

This memo examines the potential of using WWW Distributed Authoring and Versioning (WebDAV) technologies to address the problems of network configuration management. It reviews requirements and issues that have been identified in IETF network configuration management and operator requirements discussions, matching these requirements and issues with various WebDAV facilities. It concludes by identifying areas for further exploration.

Bravo. We need more of this kind of reuse-friendly work.

Which reminds me … I forgot to mention that an Internet Draft that I wrote with Dan Connolly on a related topic (reuse, in the context of registries) was published too.

I just realized that the best way to grab the WSDL of a service is probably via HTTP OPTIONS rather than HTTP GET. OPTIONS was designed to return information which describes the interface to a service. From RFC 2616;

The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI. This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.

I mentioned this on www-ws-arch.

Dave made the following suggestion for a SOAP definition;

It’s a simple way to call procedures running on other machines, on other OSes, written in other languages, using different economic systems, without being forced to pay a tax to Microsoft, IBM, Apple, Sun or the W3C.

SOAP isn’t that at all. That’s XML-RPC. Dave’s a bright guy who writes great software, but when it comes to distributed systems, there’s a lot he doesn’t understand.

The SOAP 1.2 spec defines SOAP as;

SOAP Version 1.2 (SOAP) is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. It uses XML technologies to define an extensible messaging framework providing a message construct that can be exchanged over a variety of underlying protocols. The framework has been designed to be independent of any particular programming model and other implementation specific semantics.

Which is a pretty decent definition, though not very detailed as to how one actually might use it. For a better definition, I look to SOAP’s brethren, PEP. It’s defined as;

The Protocol Extension Protocol (PEP) is an extension mechanism designed to accommodate dynamic extension of HTTP applications by software components; and to address the tension between private agreement and public specification.

Of course, SOAP isn’t tied to HTTP, but PEP didn’t really need to be either. It could also be patched to be an extension protocol for non-HTTP protocols, as SOAP 1.1 was “patched” in the form of SOAP 1.2.

Please, if SOAP has any chance of success, let’s try to distance it from RPC.

Presumably a virus/worm/whatever had a hand in a message forwarded to the Web Services Architecture WG mailing list today. Interesting, it appears as though Scott Dietzen, CTO at BEA, has moved on to Microsoft. Ow, that’s gotta hurt. 8-)

Who knows though, this could be a fake, since the message headers look weird; the message-id is from bea.com, despite the From header indicating microsoft.com. Shrug/chuckle.

Update; the archived content of the message has been removed, presumably per W3C archive editing policy. But you can still see the From and Message-Id headers.

So while at the Web Services Architecture WG face-to-face, I was chatting with an unnamed attendee about the eventual “Judgement Day” for Web services; the day when the TAG, and/or TimBL will decide whether or not Web services have anything to do with the Web. This person, who is very likable and definitely well respected in the Web services space, said that if Web services get kicked out of the W3C, their company would leave the W3C.

Hello?! Wouldn’t you think that a more reasonable response would be something like “Well, I suppose we’d have to navel gaze for a while and understand what this means. I mean, the Web is a good thing, right? And if we’re doing things that don’t respect or reuse the principles that made it work so well, we should fix that I think.” Wishful thinking, I know. Sigh.

The big news from yesterday, WS-Security is submitted to OASIS. For those who don’t think Web services have much of a future, this is really good news for the Web and the W3C, as it removes influence from the Web Services Activity, specifically the Web Services Architecture Working Group (of which I’m a member, but that I’d be happy to see go away). Of course, many Web Services proponents are quite concerned, as it puts more control in the hands of MS and IBM.