Open Standards Interoperability
Author(s) and publish date
- By:
-
-
Karl Dubost
-
- Published:
Recent blog posts about Open Standards from Paul Fremantle are being commented on different blogs.
- Why open standards and interoperability are subtly different, May 10, 2008
- Open Source versus Open Standards - May 13, 2008
He said:
My own criteria for interoperability is that there are "tested independent implementations". This means that different groups have looked at the spec, worked through it and written code. And then they have taken these implementations and tried them against each other.
It makes sense. A group of companies and organizations is developing a technology. They put all the requirements in a specification. Implementers from this group (and outside of the group) usually try to implement as it is being developed and report if the specification is unclear, bogus, or create implementations dependencies difficult to solve.
But the real test for the specification is when different groups of implementers can create interoperable applications following the specification without talking to each other.
W3C Process for implementability
For W3C specifications, the entrance criteria to go to Proposed Recommendation is double implementations of each feature. This is not mandatory but highly desirable. It really depends on the type of the technology and how the group has defined its own criteria.
Far to be perfect, it is a step in the good direction. It would not solve all interoperability issues.
| FooML | Product A | Product B | Product C |
|---|---|---|---|
| Feature 1 | Y | Y | Y |
| Feature 2 | Y | Y | Y |
| Feature 3 | N | Y | Y |
| Feature 4 | N | N | N |
| Feature 5 | N | Y | Y |
| Feature 6 | Y | Y | N |
| Feature 7 | N | Y | N |
The Process Document urges the working group to drop features which have fewer than two implementations. Clearly, features with no implementation at all should be dropped. For FooML, the dropped features would be Feature 4 and Feature 7. So the working group drops those and publishes the following table.
| FooML | Product A | Product B | Product C |
|---|---|---|---|
| Feature 1 | Y | Y | Y |
| Feature 2 | Y | Y | Y |
| Feature 3 | N | Y | Y |
| Feature 5 | N | Y | Y |
| Feature 6 | Y | Y | N |
More interoperability checking
We can easily see in the second table, that product A and C will not be interoperable for some features. We demonstrated that each feature could be implemented twice but not necessary that products were fully interoperable. The Specification Guidelines of the QA Framework can help to reduce the diversity in implementations behavior.
A class of products is a family of products that would implement, for the same purpose, the specification. For example, there is the class of visual browsers for html and the class of conformance checkers. When creating a technology it is usually wise for the Working Group to define what are the different class of products. It helps articulate the technology and define the requirements for each type. For checking interoperability, it could be required that all features in a specific class of product be implemented.
Interoperability Cycles
Basically to achieve full interoperability, it takes a lot of development cycle and testing. It requires test suites, active and live feedback from the participants of the Working Group. Even with all that, it will not be reached, but at least the user experience will be greatly improved.
Comments (0)
Comments for this post are closed.