Extensibility and Interoperability
Saturday, 3 January 2004
In his blog, Sean McGrath wonders about two potentially competing faces of standards; extensibility and interoperability.
If “compliance” to X is open-ended via an extensiblity mechanism, then “X-compliant” means very little when it comes to interoperability. This is the constant struggle of interop, how not to stifle innovation and yet avoid babelization?
Good question. Interop is what everyone looks for in a standard; it’s the whole reason that companies spend so much money and time talking to each other in organisations like the IETF, W3C, WS-I and OASIS. Although some people would find it hard to believe, standards is not the place to do your research project.
However, the interoperability that standardisation gives you is only useful if you can depend on it for a while; it would be frustrating, to say the least, if that standard that you spent three years talking about was only stable for a year. So, you need to build it for the long term, which means adjusting to changing requirements (and those you haven’t even thought of yet) and a changing landscape. You need to make it extensible.
Extensibility is a pill that the XML world is still digesting; there’s still a lot of work going on with regard to it and its much-misunderstood cousin, versioning. However, there’s already a well-understood way to reconcile extensibility with interoperability, through the profiling of standards.
Profiling
As explained in Carl Cargill’s Open Systems Standardization (pg. 91),
The functional profile describes a set of functions that are a subset of the industry standard, and which are extracted from the industry standard.
In other words, although a standard might allow any amount of extensibility and variability, profiling it provides interoperability by “locking down” some (or all) of the choices, without changing the base standard; someone whose needs aren’t met by the profile can still use the standard to get what they want.
Such a thing can be arrived at in a number of ways. For example, HTTP has been profiled by the big Web server and browser implementations; there are several features in HTTP/1.1 that aren’t widely supported, and therefore aren’t part of the market’s natural profile. It just happened; you can’t go out and find a document that explains the profile.
It doesn’t have to be this haphazard. If standards are designed to be profiled, and interested parties (vendors and users) can work together to design the profile or profiles that are important, it’s possible to effect a separation of concerns; the standards can focus on being a solid, extensible foundation that is viable in the long term, which is then tailored by use-specific profiles, which provide interoperability and immediate functionality.
This is what’s happening in WS-I for Web services, a technology that is pretty extreme in its extensibility (so much so, in fact, that it’s being profiled in stages, where the foundation profiles themselves have extensibility, for other profiles to slot into). Many of the same people who are defining the core standards of Web services (SOAP, WSDL and UDDI) are participating in the definition of the Basic Profile, in order to assure that hits the right balance between extensibility and interoperability.
Writing Profile-Friendly Standards
Moving forward, I’d like to see standards that are built to be profiled, with clearly identified and described extensibility points, and likewise clear documentation of how they use extensibility in the standards they refer to. This would make profiling considerably easier, and ensure both their long-term viability and short-term interoperability.
The choice of those extensibility points needs to be a carefully made; there may be good reasons for locking down options in a standard when there is no need for variability in a particular dimension. For example, HTTP doesn’t allow for binary data in headers, because it would make implementation considerably more difficult, for little benefit in return.
Conversely, some standards are too restrictive, and limit their applicability in the long term. An example here can be found in the burgeoning Atom format; some people don’t believe that any serialisation other than vanilla XML 1.0 angle brackets should be allowed. While this increases interoperability greatly, it may pigeonhole Atom by making applications that need to encode large amounts of binary data impractical (here, the Atom draft might be able to act as both a base standard and a profile, by specifying things in terms of the Infoset, whilst requiring XML 1.0 for documents conformant with that specification).
Another example of this is in Atom’s stepgrandfather, RSS 0.9, which places restrictions on the size of many fields. While this probably seemed like a good idea at the time (to encourage proper usage), we’ve long since grown out of this limitation. Unfortunately, it still constrains people’s feeds, because they want to be backwards-compatible. If these recommendations had been in a profile of some sort (even in the same document), we wouldn’t have this problem.
Clearly, balancing extensibility and interoperability can be tricky. The best policy may be to remember the kind of specification you’re working on when determining whether to allow an extension; in base specifications that are expected to have a long lifetime, the bar should be fairly low, whilst in shorter-lived profiles, it should be raised. Attention should also be paid to the scope of the effort; Atom is relatively small and simple compared to Web services, for example, and they require different approaches to specification and profiling to assure success.