Interoperable

From W3C Wiki

This article is a stub. You can help the W3C wiki by expanding it.

The goal of this page is to collect, curate, and distill information about what does interoperable and interoperability mean in a W3C context in general, and as it applies to the W3C Process, and the Success Criteria of (most) Working Group Charters.

This is part of the 2024 AB Priority Project: Interoperability and the Role of Independent Implementations ("3Is project").

Why

For concrete user benefits

Interoperability must provide "concrete utility to the majority of their users":

From: https://www.rfc-editor.org/rfc/rfc9518.html:

Therefore, standards efforts should focus on providing concrete utility to the majority of their users as published, rather than being a "framework" where interoperability is not immediately available.

Emphasis added.

For better behavior and solving larger problems

Interoperability encourages better behavior, and is essential to solving larger problems:

From: https://lists.w3.org/Archives/Public/public-swicg/2023Dec/0108.html

"WE BELIEVE THAT STANDARDS AND INTEROP ARE VALUABLE", in and of themselves. Yes, of course intentions matter, business models

matter, strategy matters, etc etc. But without interop and standards, none of those are useful in the least. And conversely, interop and portability,

just by itself, _forces_ certain ethical invariants, that are strictly better than the alternative.

For the key reason to participate at W3C

The benefits of interoperability are a top level reason to participate at W3C:

From: https://lists.w3.org/Archives/Public/public-swicg/2023Dec/0108.html

"We believe in standards and interop" around here. Yes, even when it comes to giant powerful entities and companies.
If you don't believe in the benefit of standards, what are you doing here [...]? Honest question, not rhetorical.

When

When do or can we make technologies interoperable?

Spec Design

The design of a technology can impact its interoperability, from earliest ideas, and in working drafts.

Interoperability risks in design:

  • Optional features — generally agreed that optional features are harmful to interoperability
    • e.g. optional JSON-LD support / "polyglot" (O'Connor 2023)
    • separates implementations into different clusters, with or without each feature. sometimes can be mitigated with "fall back" support
    • makes market pressures "choose" or "force" which "optional" features to require or not
  • Extensibility
    • enables classic step two of EEE (Embrace, Extend, Extinguish) strategy
  • Delegating functionality to a registry
    • E.g. DID — if two implementations don't support the same DID Method (in the registry), users cannot switch from one to the other. Mitigation: DID Method Resolver service(s)
  • Externally defined features — features that are defined in another spec pose an interoperability risk. If the referenced spec is well established, REC or equivalent, with a test suite, numerous implementations, the risk is low. If the referenced spec is in-progress (proposal, WD, CR), lacks a test suite, has few current implementations, the risk is high

Downsides to users:

  • data loss (formats) or loss of fidelity/performance (protocols) when switching from one implementation with optional features or extensions to one without
  • lock-in — if the data loss or loss of fidelity is bad enough, users are unable to choose to switch between implementations for their use-cases
  • ...

Spec Development

The development process of a specification can impact its interoperability, in particular processes for advancing stages, e.g. WD to CR to PR to REC.

W3C has largely focused on addressing this aspect:

  • W3C Process — requires multiple implementations
  • Charter templates success criteria
  • Test suites
  • Implementation reports

Today:

  • success criteria, roughly: "Two or more independent implementations for each feature, passing the test suite, and interoperating with each other."
  • Most WGs produce test suites for most specs
  • Most specs link to implementation reports

After REC

After a Recommendation is published, there are still challenges (and opportunities) for interoperability

Risks:

  • Implementations going away
  • No new implementations
  • Test suite going away
  • Errata unmaintained

Opportunities:

  • More new implementations
  • Growing test suite (e.g. WPT)
  • Clear errata maintenance (and ideally lower barriers to updating specs)
  • Community collaboration (Interop project)

What

What can the W3C do to increase interoperability among its specifications?

  • Mentoring on good spec design to avoid known interoperability risks
  • Identify interoperability risks earlier, and require specs to document them (e.g. today: CRs document "at risk" features) just as we document privacy & security risks
    • Possibly make an explicit part of TAG reviews
  • Require test suites setup somewhere W3C can help run/maintain them
  • Lower barriers to reporting, incorporating, publishing errata and updated specs
  • ... additional suggestions welcome

Articles

Articles, blog posts, presentations on the topic of interoperable or interoperability in standards:

See Also

Retrieved from "https://www.w3.org/wiki/index.php?title=Interoperable&oldid=117096"