W3C home > Mailing lists > Public > public-egov-ig@w3.org > April 2009

Components of Interoperability (was RE: Per our discussion, here is the session description)

From: Todd Vincent <todd.vincent@xmllegal.org>
Date: Thu, 16 Apr 2009 01:42:30 -0400
Message-ID: <61694BA0E9EA91449CB7ACCE04052D565270BF@exchange.xmllegal.com>
To: "Jose M. Alonso" <josema@w3.org>, "Novak, Kevin" <KevinNovak@aia.org>
Cc: "eGov IG" <public-egov-ig@w3.org>

The following is a follow-up to the email I wrote previously distinguishing interoperability from standardization.  Feel free to use this text as you wish if it is helpful.  Here, I break down the components of interoperability.  Standardization is a different topic, but I mention it for comparison purposes. 

Components of interoperability include:

1. Specification
2. Connected Independent Implementations
3. Testing
4. Compliance
5. Certification
6. Ongoing Maintenance (including Governance, Intellectual Property, Version Control)

I would define interoperability as the ability of two or more independently developed systems to communicate information without error and without the loss or corruption of the information.

(Note: You do not have to have all of these components to achieve interoperability.  I would say, however, without 1, 2, and 3, there is not much substance to a claim of interoperability.)

1. Specification

Precision: To achieve interoperability, a community must begin with a written specification.  Ideally, the specification is precise (unambiguous), well-written, and available in multiple formats.

Simplicity: Specifications should be as simple as possible to accomplish the intended purpose.  The intended purpose may, itself, be complicated/complex (which is fine), but the specification should not unnecessarily increase complexity (by, for example, providing more than one way to accomplish the same function or by using obscure terminology).  While this may seem obvious, it is worth mentioning because I have observed groups with members that either intentionally or unintentionally added unnecessary complexity to a specification because it served some self-interest.  

One Option per Unique Function: Specifications should not provide the ability to perform the same function in more than one way.  This is not to say that specifications should not have options.  Options are sometimes necessary.  The line is fine.  For example, an "address specification" should not provide two ways to express "country" information.  If it does, Implementation A may implement Country A and Implementation B may implement Country B, resulting in difficulty or inability to communicate Country information.  On the other hand, a specification might provide two means of making payment -- via credit card or via direct deposit.  The latter, in my view, are two different functions and therefore permissible options.

2. Connected Independent Implementations

Connected: Interoperability requires two or more *connected* systems.  Stated another way, systems must connect to interoperate.  In contrast, a widely adopted "standard" could be implemented in several systems, but those systems may never connect.  If the systems do not connect, then they cannot interoperate regardless of whether they are "standard".

Independent: Interoperability is achieved when at least two independently developed implementations can communicate.  The *independent* requirement is one that comes from the IETF.  It would not make sense to allow claims of interoperability for systems that were developed by the same person/team.  Also, Independent implementations help to validate the quality of a specification.  If the specification is sufficiently precise, simple, and limited in its options, then two independent teams of developers should be able to write systems that can communicate.  If not, the specification needs clarification.  Indeed, the IETF (at least when I participated several years ago) required independent implementations of a specification before it would advance a specification to a recommendation.

While the IETF is careful not to call its recommended specifications "standards" (many of its specifications are the backbone of modern Internet technology), it is interesting to observe that this line of thinking makes interoperability a pre-condition of "standardization."  Many people would tell you that standardization is a pre-condition to interoperability. Not so.  As I stated in my original post, the two are quite different.  Credible organizations require proof of interoperability before publishing a specification as a recommendation for wide adoption (i.e., as a "standard").

3. Testing

Claims of interoperability are meaningless without testing.  Sales people, for example, very often make false claims of compliance and interoperability.  The only way to know whether two systems can actually interoperate is to test.

Testing can be done between and among implementers of independent systems.  Testing can also be done by independent third-parties.

4. Compliance

Testing results in a determination of compliance.  

Compliance, itself, can have multiple layers.  Well-written specifications (especially those that are large) define compliance levels.  Generally, there is a "core" portion of the specification that must be implemented to achieve basic compliance.  Other parts of the specification may be identified as discreet, additional or optional levels of compliance.

5. Certification

Certification is an extension of compliance.  Consumers/purchasers of systems do not usually have the means to do the testing to determine compliance.  Accordingly, trusted parties certify that systems comply with the specification and are interoperable with other like systems, giving a system, for example, a "Good Housekeeping Seal of Approval."  Certification is only as good as the trust in the brand that stands behind the certification.  The brand is built by consistently making accurate certification claims.

(Certification should state levels of compliance as well as the specification version, e.g., HTTP 1.0 or HTTP 1.1.)

6. Ongoing Maintenance (including Governance, Intellectual Property, Version Control)

Specifications often require ongoing maintenance.  Specifications tend to evolve, either with permission or without.  Specifications that are independently forked limit the ability to achieve interoperability. (I wonder, for example, how much time and effort has been spent over the years worldwide trying to write HTML that works with multiple browsers.)

Specifications that are upgraded by the community that "owns" them present challenges to interoperability, but at least there is a community of stakeholders working more or less at the same pace in a managed process with change control.

The entire process, including ongoing maintenance, requires governance, intellectual property agreements, and version control, among other things.  (All of which is beyond the scope of this post at this late hour.)  This is, of course, why organizations like the W3C (and others) exist.

Hope this is helpful.

Winchel "Todd" Vincent III
<xmlLegal> http://www.xmllegal.org/ 
Email : Todd.Vincent@xmllegal.org

-----Original Message-----
From: public-egov-ig-request@w3.org [mailto:public-egov-ig-request@w3.org] On Behalf Of Jose M. Alonso
Sent: Wednesday, April 15, 2009 5:55 PM
To: Novak, Kevin
Cc: eGov IG
Subject: Re: Per our discussion, here is the session description


Since nobody said a word yet, my two cents.

I would recommend an article co-authored by Trond that gives a good  
overview of the issue:

I guess you've also seen the previous message. Pointers sent by  
Vassilios and Trond also hold interesting information:

Let me be a bit controversial.
One "easy" question you may try to answer wrt the text below  
"..interoperability requires standardization..." (really?)
I argue that if A and B agree on exchanging information using a  
proprietary, non-standardized format Z, they can interoperate, so why  
A and B should invest on using open standards to achieve the same  
result? ;)

tip: some sections of the first pointer address the question.

I can put it another way, maybe easier question. Can you envision  
Data.gov not using open standards? Why not?

-- Jose

ps: hope this helps somehow, it's getting late here and it's been a  
long day...
El 15/04/2009, a las 15:46, Novak, Kevin escribió:
> Comments, ideas, etc welcomed by COB today.
> Session Title (recommended): Interoperability and Web Applications:  
> Opening the Door to Access and Sharing
> Interoperability across the web and applications requires  
> standardization, thought, and planning. The presentation will  
> discuss legacy and other challenges, provide insight into the  
> available standards and processes which exist to aid movement  
> forward and review the benefits of interoperability.
> Kevin
> Kevin Novak
> Vice President, Integrated Web Strategy and Technology
> The American Institute of Architects
> 1735 New York Avenue, NW
> Washington, DC 20006
> Voice:   202-626-7303
> Cell:       202-731-0037
> Fax:        202-639-7606
> Email:    kevinnovak@aia.org
> Website: www.aia.org
> u<image001.jpg>
> America's Favorite Architecture Tops the Shortlist for International  
> Honor for the Web
> The American Institute of Architects is the voice of the  
> architectural profession and the resource for its members in service  
> to society.
Received on Thursday, 16 April 2009 05:43:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:00:40 UTC