Using an Extended Attribute File Format to Encode Product Configuration Information
Original Publication Date: 1991-Jul-01
Included in the Prior Art Database: 2005-Apr-03
The disclosed procedure eliminates redundancy, consolidates scattered/ undocumented information, increases readability, improves maintainability and better enables the automation of development processes.
Using an Extended Attribute File Format to Encode Product
procedure eliminates redundancy,
consolidates scattered/ undocumented information, increases
readability, improves maintainability and better enables the
automation of development processes.
many obstacles stand in the way of controlling
development processes in a repeatable, measurable manner:
1. Information is often scattered throughout the system, in many
2. Some of this information is stored multiple times as it gets
3. Much is stored in an extremely complex syntax.
4. Other information is not documented at all, existing only in the
minds of key individuals.
5. Many steps in the process are repetitive and boring.
6. Some of the process policies are in a constant state of flux.
The result is
that most development processes are difficult to
learn and use. Worse, these obstacles make the process hard to
change, even if the change is for the better.
disclosed here concerns consolidation of the
information required to drive the development processes for a product
into a human and machine readable format based on an extension of the
"AIX* attribute file" format.
files as they are currently used consist of "stanzas"
that represent an "object." An object can be considered to consist
of a set of attribute value pairs, hereafter called "attributes"
(Figure 1 shows an example stanza).
An example stanza
dependencies = "foo.c foo.h"
build_date = "filedate foo.o"
make_process = "cc -O foo.c $COMPILE_FLAGS"
The advantage is that attribute files are
extremely easy to
read (if the attribute names are chosen wisely), and since attribute
files are stored in ASCII form, they can be operated on with a number
of standard operating system tools (editors, etc.). This makes it
easier to automate the processes where appropriate (it is a
relatively simple matter to translate the information from the
example in Figure 1 into an AIX "makefile" format to control the
stanza can be considered to represent one
component of the product being developed, be it a source program or
an installable executable file. The information associated with the
component is encoded within its attributes. Attributes can be used
to encode the information directly or to store a "pointer" (or link)
to it where it resides elsewhere in the system. Therefore, one can
use stanzas to consolidate the information necessary to control the
The example from Figure 1 serves to illustrate....