World Wide Web Consortium Issues SOAP Version 1.2 as a W3C Recommendation:
“Web services make good on the promise of interoperable applications only when the technical foundations are shared, robust, and achieve expected performance,” explained Tim Berners-Lee, W3C Director.
So, now we just need the remaining 742 elements in the web service stack to become “real” standards, then we’re talking.
What do you get when you cross a blog and a wiki? A bliki. Martin Fowler’s Bliki is one such. Fowler will come to Denmark soon, speaking at a conference I’ve also been invited to. I need to read some of Fowler’s work. Started with Developing Patterns of Enterprise Software, but think I need to read the book.
Thomas Madsen-Mygdal has invited me to join Reboot 6, which takes place here in Copenhagen on 20 June. I want to will participate, and will try and clear the whole day and take part in the full programme. It’s an impressive programme: First, eight great speakers: Tim O’Reilly, Dan Gillmor, Marc Canter, Meg Hourihan, Cory Doctorow, Jason Fried, Scott Heiferman, and Ben Hammersley, and then an Open Space evening. And I can walk there.
I missed last week’s W3C Working Draft on Web Services Architecture (WSA), but am happy I finally found it. René is not going to like this 🙂
There’s an interesting definition of web services:
Definition: A Web service is a software system identified by a URI, whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by internet protocols.
I can live with this. And I think René can too. I think it’s more or less “compatible” with the way we talk about services in our white paper. Now, René, the good stuff comes when W3C talks about architectural styles:
We can identify two major classes of “Web services”: REST-compliant or “direct resource manipulation” services in which in which the primary purpose of the service is to manipulate XML representations of Web resources using the a minimal, uniform set of operations operations, and “distributed object” or “Web-mediated operation” services in which the primary purpose of the service is to perform an arbitrarily complex set of operations on resources that may not be “on the Web”, and the XML messages contain the data needed to invoke those operations. In other words, “direct” services are implemented by web servers that manipulate data directly, and “mediated” services are external code resources that are invoked via messages to web servers.
This makes a lot of sense to me (so much that I get a feeling I actually don’t get it at all …). Basically, I am putting W3C back on top of my list of standards/reference bodies relevant to service-oriented architecture. The WSA would be a good candidate for governments to adopt in our interoperability frameworks. It needs consolidation, of course. I notice Microsoft is absent, so it’s going to be interesting to see how it goes.
My impression is that Microsoft goes 100% for OASIS and for WS-I Basic Profile – Version 1.0 Board Approval Draft (BdAD) from 2003/03/28. The WS-I Basic Profile 1.0 consists of a set of non-proprietary Web services specifications, along with clarifications and amendments to those specifications which promote interoperability.
WSA, WS-I, WS-*, what’s the clue in all of this?
Architectural styles can be expressed in many ways. One main style we all seem to agree upon is a service-oriented architecture (SOA). W3C says that WSA is an instance of a SOA. An SOA is a specific type of distributed system in which the agents are “services”. The WS-I Basic Profile then would be an instance of WSA, but, being a Profile, might invoke some boundary issues, as we saw with RSS last week. Or is that a wrong picture?
These are busy days in the RSS community. Dave Winer thinks Microsoft is “going to fuck all of us” and steal RSS, and suggests:
We could establish a profile of RSS 2.0 and implement strict compliance with that profile in the major blogging tools. We could give that profile a name, and jointly market it to users.
Sam Ruby said “Excellent!”, and so did many others. Don Box made a proposal, for which Sam Ruby hosts a disussion thread. Mark Nottingham announced a new RSS wiki which would feed in to the RFC as well as the Profile as they evolve. Jørgen Thelin will work on the XML schema for the Profile. Timothy Appnel asks the basic question:
At what point does the specification stop and extensible modules begin?
Tim Bray jumps in and uses the S-word, “Standardization”, and says:
Standards happen when someone is willing to get behind them and burn the cycles and the brain cells and not stop till it’s done. If someone’s willing to find the time, it can be done, otherwise not.
Tim goes through the various potential standardisation bodies, and ends up picking IETF, and supports the RFCifying of RSS 2.0 that Mark Nottingham started a few weeks ago. Don Box suggests the standardisation process is taken to OASIS instead, but doesn’t seem to have any hard opinions on this.
Many in the debate seem to take for granted that RSS 2.0 has won. This is a foregone conclusion, and is challenged by many, for example,
Ben Trott and Danny Ayers, who sticks with RDF-based RSS 1.0. Maybe they should forth and suggest standardisation through W3C (who uses RSS 1.0).
But wait, in comes a new specification that is intended to act as a bridge between RSS 2.0 and RSS 1.0 on a technical level. Simple Semantic Resolution (SSR) Module for the RSS 2.0 syndication format. The purpose of SSR is to provide a mechanism by which the semantics of an RSS 2.0 document can be unambiguously resolved to an RDF model. Will this really work? It would be great if it would.
In terms of the standardisation process, the idea of using a Profile is an intersting trick, and probably the right way to take with RSS. Profiles are suitable for emerging technologies, and RSS is still an emerging technology.
As I understand the profile concept it is more or less like American English and British English, which could be seen as two profiles of the same language. It’s a mess having two ways of spelling the S-word, standardisation and standardization, but somehow it works, probably due to the two profiles being used literally by millions every day. And, if anyone should ever dream of standardis/zing English, they’d better get up early, because that’s going to be a long ride.
One of my work projects is about creating what we call a Reference Profile for eGov Interoperability. This is basically the Danish pendent to UK’s e-GIF, Germany’s SAGA, i.e., a national Interoperability Framework. The Reference Profile will contain technical policies and specifications which are formally recognised by the Danish government.
I’m happy we chose to call our framework a profile, although the Reference Profile is much more “meta” than, say, the Basic Profile Version 1.0 (Board Approval Draft, BdAD). In fact, our Reference Profile could end up refering to the Basic Profile.
It is worth noting that it was only this week W3C released SOAP as a Proposed Recommendation (that’s one step closer to becoming a W3C Recommendation, but we’re not quite there yet).
The Danish XML Committee is working on an Integration Handbook featuring (Part 2) guidelines for how to use web services in integration projects. A draft is available for pre-consultative comments (you can send comments to me).
Mark Nottingham has had it with the lack of a formal RFC for RSS, and says Let’s try this, and submits an IETF Internet Draft on RSS2.0.
J�rgen Thelin fully supports the proposal, while Sam Ruby is about as ambivalent as Dave Winer on this one. Dave Winer notes the news by pointing to an old DaveNet-piece called Submission, where he says Submission is not my nature.
So, there we are. I certainly think having a formal RFC is progress, and an important step ahead in terms of standardisation.
The new RSS overlords, Don Box and Sam Ruby, wants to namespace-qualify RSS elements with a well-known namespace. Chances are, I think, that they’ll get their wish fullfilled, eventually.
I have changed the default feeds from GotzeLinked to RSS 2.0 using xhtml:body.
As I demonstrated with my blogroll, OPML has its uses. I went further and built John G�tze’s OPML Directory Browser, which is an OPML-driven directory browser for browsing loosely coupled OPML-files from my own GotzeLinked. The OPML-browser is based on Austin Marshall‘s PHP-OPML toolkit. Thanks to Austin for creating this nice tool.
I wanted to use a semi-large directory (GotzeLinked has more than 1000 links with descriptions) to demonstrate an architectural principle, loosely coupling, in practice. Rather than having one large file with all data, I use a meta-OPML-file (“father”) and a set of individual, thematic (category-based) OPML-files (“siblings”). I created a new (?) attribute called opmlurl, with which I in the father-file points to the OPML-files of each sibling.
In terms of interoperability, OPML sucks. It is not “real” XML – it’s more like HTML on steroids actually, using non-standard attributes to store important data, rendering it very difficult to work with in the modern XML-world. That, together with the fact that the OPML specification is closed (Dave Winer has the IPR on the spec), and non-specific about attributes, makes it virually impossible to make OPML-systems interoperable. Some use “url” to describe everything available on an URL, while others use “htmlurl”, “xmlurl”, or “opmlurl” (like I do) to distinguish between various formats.
Ray Grieselhuber announces OML and writes that
the reason I decided to go forward with OML, is that as the number of applications using an outline XML format increase, with the current extension mechanism in place, it is going to be very difficult for these applications to interoperate. Not only is there nothing that specifies the names of the most common attributes, but the fact that there can be any number of varying attributes in the outline element, is in the opinion of many, a big problem.
Hence, OML is less attribute-oriented than OPML, and instead uses a number of well-defined outline-attributes, text, created, etc, but also differs form OPML in using two important data-bearing elements, data and item.
I’m tempted to shift to OML … on the other hand, I don’t really give OML much of a chance. I don’t know Grieselhuber’s real mission, but I would bet he’d be aiming at getting OPML to embrace the OML spec. That would IMO be the best solution. Please don’t repeat the RSS-history.
It’s time again for Dave Winer to urge us to use OPML. Dave put up an interesting artivcle, How to implement an OPML directory browser.
That got people like Phil Windley to look into OPML again. And me too.
You won’t notice it, but my blogrolls are based on OPML, transformed to HTML on the fly. Since Dave’s last call, I provide a full OPML-version og my GotzeLinked, and use my Blogging-category there to maintain my blogrolls. Now, thanks to Defconzero‘s PHP-OPML toolkit, I have retired the ol’ RSS-aggregator and shifted to OPML.
If you’re not into outliners, OPML makes little sense. But even outside the “outliner-business”, OPML is worth looking into, and I have already seen one killer app using OPML. I’m sure it won’t be long before we see another OPML-based killer app.
One of the areas OPML is around is in the exploding aggregator market. Which desktop aggregator do you use today? These days, my favorite is NewsMonster, which has a convenient OPML-integration mechanism, although as far as I can tell, no OPML-export feature (like Amphetadesk).
For OPML to expand – and I do think there is a great potential here – some standardisation work is needed. We need a formal OPML Schema, and a more substantial specification, and ultimately, a standards body to take ownership of the specs and stuff.
Let’s see how it goes with RSS and its standardisation. J�rgen Thelin is continuing working on a RSS 2.0 Scema. Interesting stuff.