Forward compatibility

Type of design interoperability From Wikipedia, the free encyclopedia

Forward compatibility or upward compatibility is a design characteristic that allows a system to accept input intended for a later version of itself. The concept can be applied to entire systems, electrical interfaces, telecommunication signals, data communication protocols, file formats, and programming languages. A standard supports forward compatibility if a product that complies with earlier versions can "gracefully" process input designed for later versions of the standard, ignoring new parts which it does not understand.

The W3C's Technical Architecture Group (TAG) defines the concept more formally: "a change in the definition of a language is forward compatible if consumers of the original language can correctly process text written for the evolved version of the language".[1]

The objective for forward-compatible technology is for old devices to recognise when data has been generated for new devices.[2]

Forward compatibility for the older system usually means backward compatibility for the new system, i.e. the ability to process data from the old system; the new system usually has full compatibility with the older one, by being able to both process and generate data in the format of the older system.

Forward compatibility is not the same as extensibility. A forward compatible design can process at least some of the data from a future version of itself. An extensible design makes upgrading easy. An example of both design ideas can be found in web browsers. At any point in time, a current browser is forward-compatible if it gracefully accepts a newer version of HTML, whereas how easily the browser code can be upgraded to process the newer HTML determines how extensible it is.

Design principles

The W3C Technical Architecture Group has documented a family of substitution rules that enable forward-compatible language design. Each rule specifies how a consumer should behave when it encounters constructs it does not recognize:

  • Must ignore unknowns — a consumer that encounters an unrecognized construct must continue processing, treating the construct as if it were not there.[3]
  • Must accept and discard unknowns — a consumer must accept unknown constructs at defined extension points and then discard them.[3]
  • Must accept and preserve unknowns — a consumer must accept unknown constructs and, when forwarding or transforming the content, preserve them for downstream consumers.[3]

These rules underlie forward compatibility in widely deployed languages and protocols. HTTP/1.1, for example, specifies that unrecognized header fields should be ignored by the recipient and must be forwarded by transparent proxies — a direct application of the "preserve unknowns" rule.[4]

Examples

Telecommunication standards

The introduction of FM stereo transmission, or color television, allowed forward compatibility, since monophonic FM radio receivers and black-and-white TV sets still could receive a signal from a new transmitter.[2] It also allowed backward compatibility since new receivers could receive monophonic or black-and-white signals generated by old transmitters.[citation needed]

Video gaming

HTML

HTML is designed to treat all tags in the same way (as inert, unstyled inline elements) unless their appearance or behavior is overridden; either by the browser's default settings, or by scripts or styles included in the page.[14] This makes most new features degrade gracefully in older browsers. One case where this did not work as intended was script and style blocks, whose contents are meant to be interpreted by the browser instead of being part of the page. Such cases were dealt with by enclosing the contents within comment blocks.[15] More generally, HTML's forward compatibility follows a "must ignore" design: early HTML specifications required that unrecognized start and end tags be mapped to nothing during tokenization, which is what allowed later elements such as <img> to be introduced without breaking existing browsers.[3]

As there is no mandatory upgrade of computers or web browsers, many web developers use a graceful degradation or progressive enhancement approach, attempting to make newly created websites that are compatible with older computers and web browsers, usable when JavaScript is disabled or on a slower connection, while still taking advantage of faster hardware and better JavaScript support in more modern web browsers, when available.[16]

Optical media

Each of the three most common 12 cm optical media formats (CD, DVD, and Blu-ray) was first released in read-only form years before writable forms were available. Within each format, there is both forward and backward compatibility, in that most older read-only drives and players can read (but not write) writable media in the same format, while read/write drives can read (but not write) old read-only media. There is no forward compatibility between formats; a CD player, for instance, can't read a DVD (a newer format), not even the audio tracks. There may be backward compatibility for better marketability (such as a DVD player playing an audio CD), but it is not intrinsic to the standards.[17]

Relation to the robustness principle

Forward-compatible design is closely related to the robustness principle articulated by Jon Postel in RFC 761 (January 1980): "be conservative in what you do, be liberal in what you accept from others".[18] The "liberal in what you accept" half of the principle describes the stance that a forward-compatible system takes toward unrecognized input; the "must ignore unknowns" rule can be read as a specific implementation of it.

Formally defining forward compatibility has nonetheless proven difficult. Members of the W3C Technical Architecture Group treated the definition of forward and backward compatibility as an open problem in 2007, in part because the concept describes a relationship to future versions of a language that do not yet exist.[19]

Not upwardly compatible

Some products are not designed to be forward compatible, which has been referred to as NUC (not upwardly compatible). In some cases this might be intentional by the designers as a form of vendor lock-in or software regression.

For example, a cubicle producer considers changing their cubicle design. One designer promotes changing the footprint from 4-foot (1.22 m) square to 1.2-meter square. Immediately, the sales manager calls "NUC" and the problem is understood: if the footprint changes and existing customers are considering buying more from the producer, they will have to fit a different sized unit in an office designed for the 4-foot square cubicle.

Planned obsolescence is a type of upward compatibility, but rather than adopting a policy of backwards compatibility, companies adopt a commercial policy of backwards incompatibility so that newer apps require newer devices.

See also

References

Related Articles

Wikiwand AI