The difficulty and expense of handling properties comes from this univeral inheritance possibility. The list of properties which are assigned values on any particular FO element will not generally be large, but a current value is required for each property which applies to the FO being processed.

The environment from which these values may be selected includes, for each FO, for each applicable property, the value assigned on this FO, the value which applied to the parent of this FO, the nearest value specified on an ancestor of this element, and the initial value of the property.

This determines the minimum set of properties and associated property value assignments that is necessary for the processing of any individual FO. Implicit in this set is the set of properties and associated values, effective on the current FO, that were assigned on that FO.

This minimum requirement - the initial value, the nearest ancestor specified value, the parent computed value and the value assigned to the current element - suggests a stack implementation.

One possibility is to push to the stack only a minimal set of required elements. When a value is assigned, the relevant form or forms of that value (specified, computed, actual) are pushed onto the stack. As long as each FO maintains a list of the properties which were assigned from it, the value can be popped when the focus of FO processing retreats back up the FO tree.

The complication is that, for elements which are not automatically inherited, when an FO is encountered which does not assign a value to the property, the initial value must either be already at the top of the stack or be pushed onto the stack.

As a first approach, the simplest procedure may be to push a current value onto the stack for every element - initial values for non-inherited properties and the parental value otherwise. Then perform any processing of assigned values. This simplifies program logic at what is hopefully a small cost in memory and processing time. It may be tuned in a later iteration.

	Stack implementation

Initial attempts at this implementation have used LinkedLists as the stacks, on the assumption that random access would not be required pushing and popping of list elements requires nearly constant (low) time no penalty for first addition to an empty list efficient access to both bottom and top of stack However, it may be required to perform stack access operations from an arbitrary place on the stack, in which case it would probably be more efficient to use ArrayLists instead.

An individual stack would contain values for a particular property, and the context of the stack is the property class as a whole. The property instances would be represented by the individual values on the stack. If properties are to be represented as instantiations of the class, the stack entries would presumably be references to, or at least referenced from, individual property objects. However, the most important information about individual property instances is the value assigned, and the relationship of this property object to its ancestors and its descendents. Other information would include the ownership of a property instance by a particular FO, and, in the other direction, the membership of the property in the set of properties for which an FO has defined values.

In the presence of a stack, however, none of this required information mandates the instantiation of properties. All of the information mentioned so far can be effectively represented by a stack position and a link to an FO. If the property stack is maintained in parallel with a stack of FOs, even that link is implicit in the stack position.