This interface is optional, since a binding may not support actively notifying changes in it's value. Note, however, that in case this interface is not supported, the bound component cannot react on value changes, and will thus override any values which are set by an instance other than itself.

An ValueBinding may be known to one ore more components supporting the XBindableValue interface, which all work with this binding. However, they will not own the ValueBinding. The ownership is with another instance, which may also decide to obsolete the ValueBinding for whatever reasons (e.g. because the data model which the binding reflected died). For this reason, a ValueBinding must offer a possibility to be obsoleted by it's owner, and to notify this obsoletion to other interested parties, such as XBindableValues.

For instance, you could imagine a ValueBinding which represents a cell in a spreadsheet document, and whose value is readonly as long as the spreadsheet is locked.

As long as this property is true, the value binding should throw a InvalidBindingStateException when its XValueBinding::setValue method is invoked.

In a more complex scenario, where different form controls are bound to different values, which all are part of a larger data structure, some of the items in this data structure may not be relevant currently. This is indicated by the Relevant property being false.

XBindableValues which are bound to this binding may or may not react in certain ways on the (ir)relevance of their bound value.

One possible reaction could be that user interface elements which are associated with the XBindableValue are disabled as long as Relevant is false.