Forward_compatibility

Forward compatibility

Forward compatibility (sometimes confused with extensibility) is the ability of a system to gracefully accept input intended for later versions of itself.

A forward-compatible system is expected to gracefully handle input which is intended for a newer version, by ignoring the unknowns and selecting the known subset of the data that the system is capable of handling. Forward compatibility is harder to achieve than backward compatibility because a system needs to cope gracefully with an unknown future data format or requests for unknown future features. Backward compatibility does not have this issue because it accepts a known data format.

An example of forward compatibility is a web browser ignoring the HTML tags that it does not (yet) recognize. It is typical for forward compatible systems to ignore unknown data or application instructions.

Many application software systems are designed with a robust and self-sufficient systems architecture so that they can operate adequately even when input for a 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.

A code 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).