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

Todd, thanks much, very well put.

I'm copying Oscar and attaching this one to ISSUE-7 for him to review.

-- Jose

El 16/04/2009, a las 7:42, Todd Vincent escribió:
> Jose/Others:
>
> 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.
>
>
> Thanks,
>
> Todd
> ===========================
> 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
>
> Kevin,
>
> 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:
> http://www.epractice.eu/en/document/287920
>
> I guess you've also seen the previous message. Pointers sent by
> Vassilios and Trond also hold interesting information:
> http://lists.w3.org/Archives/Public/public-egov-ig/2009Apr/0057
>
> 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>
>> AIA NAMED BEST ASSOCIATIONS WEBSITE FOR THE 12th ANNUAL WEBBY AWARDS!
>> 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 15:05:33 UTC