Data and Value Attributes

Attributes in a Processing Data class can be classified into data attributes and value attributes. Data attributes basically act as data containers and they are usually of complex types such as arrays.

On the other hand, value attributes act as auxiliary information related to the data attributes. They are always of simple types such as integers or floating point. Value attributes can in turn be divided into informative value attributes and structural value attributes. Informative value attributes are simple value containers that are used to interpret the Processing Data content. A modification in such attributes does not imply a change in the related data. Conversely structural value attributes are meant to inform but also to modify the internal structure of Processing Data objects. An example of such an attribute is the ``size'' of a given Processing Data object, its value must be obviously synchronized to the size of the internal buffers and a change in it means a resizing of all the buffers.

But it is not always obvious to identify whether a value attribute is informative or structural and its interpretation is many times a design decision. The same value attribute can be interpreted as informative or structural in different Processing Data classes, depending on what the designer decided. An example of such a dual value attribute could be the ``scale'' (linear or logarithmic) of a particular data. One may choose to implement it as purely informative in the sense that modifying it would not imply a data conversion. In this situation the responsibility of keeping data and value attributes synchronized is left to the Processing Data class user. But one may also choose to implement it as structural and decide to convert data any time the scale value is modified.

It is generally better to implement ambiguous value attributes as structural therefore removing the synchronization responsibility from the user. But in some cases the cost and logical complexity of adopting this solution may recommend otherwise.

2004-10-18