Forward compatibility
From Wikipedia, the free encyclopedia
Forward compatibility (sometimes confused with extensibility) is the ability of a system to accept input intended for later versions of itself.
Forward compatibility is harder to achieve than backward compatibility because it needs to cope gracefully with an unknown future data format or requests for unknown future features. Backward compatibility does not have this issue as it accepts known data format.
An example of forward compatibility is when the specification tells a web browser to ignore those HTML tags which it does not recognised. It is typical for forward compatible systems to ignore obsolete data or application instructions .
Software applications attempting to provide backward compatibility with older operating system versions must pay close attention to the software logic used in responding to the identified operating system. Often, backward compatibility is provided when an earlier operating system version has been identified, and special behavior is provided for each earlier version. Some applications will stop and exit, also known as “error exit”, when the operating system version cannot be identified. Others will go to a particular version of the application, for example, to a “plain vanilla,” special default version (one using/requiring the least advanced or technically complex features). If the application has no tolerance for unexpected behavior, an “error exit” may achieve the desired result at the expense of forward compatibility. However, if the potential benefit of forward compatibility outweighs its cost, a standard behavior (forward compatibility) is generally provided, even when the application cannot identify the operating system’s version.
Many application software systems are designed with a robust and self-sufficient systems architecture that they can operate adequately even when input for a far more advanced version is entered.
In all cases, when the application system accepts the input data or operating system is not as expected, it will produce an output that will identify the problem accurately for the user.
This article was originally based on material from the Free On-line Dictionary of Computing, which is licensed under the GFDL.
[edit] An Example
Assume that version v0 of a program expects inputs of the form <t>X</t>, where t is an envelope containing some data X. Version v1 requires some extra functionality and thus it is also able to accept inputs of the form <s>X</s>, where s is a specialization of t. Now v0 cannot read the input <s>X</s>, since v0 has no knowledge that s can be treated as t. It would appear that since s is a specialization of t, the new input could have been coded as <t type="s">X</t> where the ‘type’ attribute denotes the specialized nature. This is indeed a better form of the input, but if v0 wasn’t designed to gracefully ignore the ‘type’ attribute, this won’t present forward-compatibility either. In fact, the design of v0 determines its forward compatibility. The choice now is simple: forward compatibility or new functionality?
If the choice is new functionality, then we break forward compatibility. But it is important now to build into v1 the ability to gracefully treat future inputs we could foresee (e.g. ignore attributes such as ‘type’ that the program does not understand).
