Electrical computers and digital data processing systems: input/ – Input/output data processing – Input/output command process
Reexamination Certificate
2000-04-07
2004-05-25
Gaffin, Jeffrey (Department: 2182)
Electrical computers and digital data processing systems: input/
Input/output data processing
Input/output command process
C710S029000, C710S033000
Reexamination Certificate
active
06742054
ABSTRACT:
FIELD OF THE INVENTION
This invention relates to computer systems and, more particularly, to information processing systems that transform data from one form to another.
HISTORY OF THE PRIOR ART
Computer applications often need to use data prepared by different computer applications. For example, when a bill is paid by a company using a first accounts payable application, some of the information associated with that bill needs to be forwarded to a second general ledger application, to be recorded for the company's financial statements. It is possible that the first and second applications were provided by two different companies and that the exact format and content of the data representing the bill differ. For example, the first application may represent an account number as two data items: a department code of three characters and an account of up to four digits; while the second application represents an account number as a single data item of up to ten digits. To allow the account data from the first application to be used by the second application, the department code and account data items from the first application can be concatenated into the single ten digit account number data item when the data associated with the bill is forwarded to the second application.
However, if the data from the first application is transferred to a third application requiring yet another format for an account number, this solution may not work. To obviate this problem, instead of modifying the first application, the billing data from the first application may be intercepted and modified by an “interceptor” computer program not associated with either the first or second application. In this way, neither application need be modified; and, if either the first or the second application changes, only the interceptor program must change.
Large companies can have thousands of computer applications that must communicate data with each other. Because an interceptor program must be written for every pair of communicating applications, this could result in an unmanageable number of interceptor programs. To help alleviate this situation, general purpose software programs have been devised to transform data from one form to another. To further facilitate matters, standards have been created for various aspects of the representation of data.
Data that is exchanged between applications is broken into messages, each containing data items. In the above example, the data items associated with a bill (the amount, account number, date paid, vendor, and the like) collectively form a single message.
One can separate the content of a message into encoding and semantics. Encoding deals with the many issues associated with representing the data on the particular medium of exchange (which could be, for example, a punched card, magnetic disk, or a telephone wire). It also includes number and character representation, separation of the different data items in a single message, the mechanism for naming the data items, how characters are represented, and other issues necessary to convey the semantics of the message.
Nearly all aspects of message encoding are specified by means of standards. One of the most popular standards in this area is the Extensible Markup Language (XML) specification. This specification provides a method of encoding where data items can be named and structured into named groups.
Although data transformation software must deal with encoding issues, they are not important for this description and will not be discussed further. Only the semantic aspects of data transformation are considered.
The semantics are the meaning of the message. Semantics include the name of each of the data items, the order and structure in which the data items appear in the message, and the meaning of the values of each of the data items. The remainder of this description refers to a data item containing a single value as a “field.” Fields in a message can be arranged in named groups called “containers.” For example, a person's name can be represented as follows:
PersonName (container)
FirstName (field)
MiddleInitial (field)
LastName (field)
In this example, referring to the data item “PersonName” is a reference to the entire name. When there are hundreds and maybe thousands of data items associated with a message, grouping is necessary to easily examine and manipulate parts of the message. Containers can hold fields and other containers. Fields or containers may be repeated either a fixed or variable number of times. Consider the case of a message representing a customer that includes a history of all of the orders that customer has placed. Typically, this is represented by a container that holds the information associated with each order; and that container repeats for a variable number of occurrences. When a field or container can repeat, this is called a “sequence.”
The definition of the content of a message is called a “schema” and is represented using a “tree.” A tree is a method of relating multiple entities that are called “nodes.” Each node has a single parent and may have zero or more children. The top most node, that is, the one node without a parent is called the “root.” If a node has both a parent and one or more children, is it called an “intermediate.” Finally, a node with no children is a “leaf.” An example of a tree is illustrated in FIG.
1
. The root and intermediate nodes are containers (and possibly sequences), and the leaf nodes are fields.
For the purpose of a transformation definition, there is an input schema, which defines the input message and an output schema defining the output message. Here is an example of a simple schema:
Customer (container)
Name (field)
Address (field)
Orders (container and sequence)
PartNumber (field)
Quantity (field)
Price (field)
When referring to a field in the schema, the field name is normally qualified with its enclosing containers. In the above example, the PartNumber field would be referred to as Customer.Orders.PartNumber.
A transformation consists of the input and output schema and all of the rules that describe how to build the output message from the input message. Typically, a transformation processes a single input message producing a single output message. Transformations are capable, however, of processing one or more input messages producing one or more output messages.
There are several different types of transformations. One type is used for copying data from an input field with one name to an output field with a different name. A second type of transformation performs a function on an input field that alters it in some way and sets an output field to the result of that function. An example is converting a date from Jun. 23, 1998 to Jun. 23, 1998. A third type of transformation fabricates an output field either from multiple input fields or from a portion of a single input field. Fabricating may also include performing a function as mentioned above.
A fourth type of transformation creates a sequence of output fields based on a sequence of input fields. For example, in the message above containing a customer and the associated orders, the output message may contain a sequence of orders each of which corresponds to an order in the input message. Further, performing a filtering operation to exclude some of the orders from the output might be necessary. A filtering condition specifies the criteria for selection of input data before it is considered for further processing. An exemplary filtering operation might select all orders whose total amount was over one hundred dollars.
A fifth type of transformation alters the structure of the data. In the customer example above, suppose it was desired to have multiple messages produced from the single customer message, where there is one output message per order. Such an output message would have fields related to both the customer and the order. More complicated structural transformations which are sometimes required will be discussed below.
Typically, the details of the semantic structure of the message
Casiano Angel
Gaffin Jeffrey
Kaufman Marc S.
Nixon & Peabody LLP
Vitria Technology, Inc.
LandOfFree
Method of executing a data transformation specification does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method of executing a data transformation specification, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method of executing a data transformation specification will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3214913