Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Using an Extended Attribute File Format to Encode Product Configuration Information

IP.com Disclosure Number: IPCOM000121056D
Original Publication Date: 1991-Jul-01
Included in the Prior Art Database: 2005-Apr-03
Document File: 7 page(s) / 247K

Publishing Venue

IBM

Related People

Hambrick, GM: AUTHOR

Abstract

The disclosed procedure eliminates redundancy, consolidates scattered/ undocumented information, increases readability, improves maintainability and better enables the automation of development processes.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 20% of the total text.

Using an Extended Attribute File Format to Encode Product Configuration
Information

      The disclosed procedure eliminates redundancy,
consolidates scattered/ undocumented information, increases
readability, improves maintainability and better enables the
automation of development processes.

      Currently, 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
different formats.
2.   Some of this information is stored multiple times as it gets
scattered.
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.

      The invention 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.

      Attribute 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).
                                  Figure 1.
                              An example stanza
                 foo.o:
                    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
build process).

      Further, each 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
development process.

      The example from Figure 1 serves to illustrate....