From W3C Wiki
< Evolution
Revision as of 12:12, 10 April 2012 by Larrymasinter (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Why standards?

insure interoperability 
the standard specifies the rules for interconnection (of interfaces, protocols, file formats, languages), such that multiple implementations, if conforming to the specification, will interoperate.
Meet societal needs 
the standard specifies rules for implementation such that an implementation conforming to the standard exhibits some social good not directly related to interoperability (performance, security, ease of use, privacy, internationalization, accessibility).

Evolution of interfaces, their implementations and specifications

When there are multiple implementations, evolution requires coordinating the evolution the interface through progress in the implementations and the specifications. The process by which specifications become standards involves coordination between multiple parties.

Specifications and implementations can allow for evolution and extensibility:

[Versioning Strategies] lays out some strategies; in particular, the case where a previous specification didn't match widely deployed implementations.

dividing a specification into multiple components may help allow them to evolve independently
references to evolving specifications in a series 
the normative references of a specification may point not to a particular edition or version of a specification or standard, but explicitly allow the reference to evolve.
use of identifiers and registries 
as expanded in other sections of this document.

Specification and implementation and interface evolution need to be kept in sync, while not making old conforming implementations non conforming, etc.

[IAB-extension] has a discussion of costs and benefits, but it tries to separate 'routine' and 'major' extension categories, based on the impact adding a new identifier has on the base protocol/language. Some extensibility points have requirements that are not obvious or well-documented or well-understood, and could affect proper functioning in some way... if so, a process that has some qualification of whether it has passed meaningful review, whether someone other than the inventor of the registry item can update its specification. Lower cost of evolution, Preserve Interoperability, Matching reality, allow for private extensions, give implementers guidance about what is actually needed to be interoperable with other deployed systems, allow discovery of what is meaningful and important, insure the information is timely, doesn't go out of date, disappear, make sure that it is stable and evolvable at the same time.