System and method for comparing extensible markup language (XML) documents

A system and a method for comparing Extensible Markup Language (XML) documents includes providing two XML documents as XML objects to a comparison tool and providing a list of XML items to be either included or excluded from the comparison. The comparison tool provides an application program interface (API), which allows it to be plugged into any application. The adaptability of the comparison tool to any application and the ability to exclude items from the comparison, or limit the comparison to specific items, provide for a flexible tool that improves performance for a user.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to document management and, more particularly, to a system and a method for comparing extensible markup language (XML) documents such that certain elements and attributes are excluded from the comparison process.

2. Related Art

It is common when generating a document, such as a text file or spreadsheet, to draft, review, and revise the document multiple times before a final document is produced. In the electronic age, multiple drafts and revisions of a document may be saved as different versions on a computer or network in order to capture content changes and modifications made between drafts. Often, one may wish to compare versions of a document to determine what changes have been made. For example, if a document is being prepared by more than one person, changes made between versions may not be known to each person preparing the document. Software application comparison tools have been created to provide an easy mechanism for comparing documents and/or versions of a document to highlight changes made.

Current document comparison tools typically are file based, such that the tool or software component takes two flat, or text files, and compares the two files against each other. A common result of such a comparison tool may be a merged result of the two documents, with modifications denoted in a particular manner, such as, for example, deleted content may be struck through while added content may be underlined.

Shortcomings of such comparison tools include a limitation to a specific application or to a specific type of document, and the inability to limit the comparison process to specific content within the documents. Often, certain portions of a document are irrelevant for comparison purposes. For example, when versions of a document are compared, the comparison may yield different version numbers and timestamps, even though such differences may not be relevant to a user generating the comparison. On the other hand, a user may wish to know whether a change has been made in only a specific portion of a document, making any modifications occurring in the rest of the document irrelevant. No current comparison tool allows for a user to be selective in determining specific content for a comparison process.

Additionally, as stated above, most, if not all, tools are file-based executable programs, which generally are limited to a specific application or document type. Thus, a need exists for a comparison tool that may be flexibly used between different applications and document types, and that provides for a selective comparison between documents.

SUMMARY OF INVENTION

The present invention relates to a system and a method for performing a comparison between documents utilizing a list of data items to be excluded from the comparison process. Specifically, the system uses extensible markup language (XML) documents to represent documents or files to be compared, and further uses a hierarchical structure known as a “tree” structure to represent the actual content for the comparison process.

The system of the present invention includes a comparison tool created in an object-oriented programming language (OOPL), such as, for example, JAVA™. The comparison tool provides an application program interface (API) that allows the comparison tool to interact with, or be plugged into, any application capable of interacting with such a language. This allows the comparison tool to be utilized by multiple applications without having to be specialized for each application, thereby increasing the flexibility of the comparison tool of the system. A preferred embodiment of the present invention is disclosed below in which JAVA is used. However, one of ordinary skill will recognize that the present invention is not limited to the use of JAVA and, instead, may use any object oriented programming language.

The comparison tool of the system compares two XML documents, which have been formatted into an XML object representation (XML object), such as the Document Object Model (DOM) established by the World Wide Web Consortium, in order for the comparison tool to manipulate the XML documents. Unlike conventional XML comparison tools, which are limited to performing a straight comparison between XML documents, the comparison tool of the system also incorporates a third XML object representing a list of items from the XML documents to be excluded from the comparison (exclusion list). The comparison tool generates a merged Result XML object, including the items specified in the exclusion list. The Result XML object then may be manipulated according to the needs of a user

Alternatively, the third XML object may represent a list of items from the XML documents such that the comparison process is limited only to those specific items. This is beneficial when many changes have occurred between versions of a large document or file, but the relevant portions of the document are few.

In an XML object, an XML document is represented as a logical “tree” having objects, or “nodes,” located in a hierarchical branching structure. This tree structure is made up of elements and attributes, where an element represents an actual item in the hierarchy of the document and may have a data value, and an attribute represents data that describes an element. Each node may contain one or more elements and one or more attributes, depending on how the tree diagram is structured. The top node or the “root” node is also referred to as the parent node, with each node descending from it referred to as a child node. Using XML, a document transformed into an XML object may be utilized and manipulated outside of its specific application.

According to another embodiment of the present invention, a method for comparing XML documents includes the steps of the system receiving two XML objects, which represent two XML documents, from one or more sources, and the system receiving a third XML object representing a list of items, divided into elements and/or attributes, to be excluded from a comparison process. The system performs the comparison process between the two XML objects, which represent the two XML documents, by traversing the nodes of the first received XML object and then traversing the nodes of the second received XML object to determine whether elements and attributes have been modified, inserted, and/or deleted between corresponding nodes. The system also determines whether elements and/or attributes have been added and/deleted between the two XML objects. Elements and attributes identified in the third XML object, the exclusion list, are ignored regardless of whether changes have occurred to them.

Changes are indicated in the node containing the changed element or attribute. Notification of a change in a child node is made in each parent node along the path to the modified child node, up to the root node, which is annotated or notified that a change has occurred in one or more child nodes descending therefrom. This allows an application to determine initially that a change has occurred somewhere in the document without having to locate the specific details. For a user who simply wants to know whether any changes have occurred between two documents, this method provides a quick and simple response to such an inquiry.

The method further includes the step of the system generating a processed result as a Result XML object by merging the two received XML objects and annotating nodes where changes have occurred. The system also passes through to the Result XML object the listed elements and attributes excluded from the comparison process so that no data is left out of the processed result. The excluded elements and attributes appear in the Result XML object as unchanged. In another step of the method, the system transmits the Result XML object in accordance with an application interacting with the system. Because the processed result is generated as an XML object, and not a text file, any application capable of manipulating XML objects may receive and utilize the processed result in accordance with a user's needs.

Advantageously, the system may offer a user the choice of either a straight comparison of two XML documents or a comparison involving an exclusion or inclusion list. Providing both methods for comparing XML documents increases the utility of the system.

The features of providing an exclusion list of XML items and passing any change notification up to the root node produces a system with greater flexibility and utility than conventional comparison tools. Advantageously, less time is spent reviewing the merged result, which contains only the relevant changes according to a user's needs. By providing an API, the system can be plugged into any application compatible with an object-oriented programming language, providing greater flexibility than conventional document comparison tools. By being object oriented, less time and computer resources are needed because there is no need to convert XML objects to flat, or text, files in order to perform a comparison process. Overall, the time and costs associated with document comparison are greatly reduced.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

FIG. 1illustrates a system for comparing XML documents, according to a preferred embodiment of the present invention. The system includes an XML compare tool101, which is created or written in an object-oriented programming language (OOPL), such as JAVA. The compare tool101includes an application program interface (API)106, which allows the compare tool101to interface with any application compatible with the OOPL. The compare tool101receives XML documents in the form of objects, such as a DOM object. Thus, the compare tool101may receive a first XML object102and a second XML object103, which represent two XML documents submitted for comparison. The compare tool101may also receive a third XML object104, which represents a list of document items, or XML items, to be excluded from the comparison process. Alternatively, the third XML object104may also represent an inclusion list of XML items which is used when a user wishes to compare only those listed XML items between the first XML object102and the second XML object103.

The compare tool101generates a processed result, such as a Result XML object105, which is a merged result of the first XML object102and the second XML object103. The compare tool101may transmit the Result XML object105to a destination in accordance with instructions from an application the compare tool101is working with.

Because the compare tool101includes an API106, this single tool is not limited to interfacing with only one application, but may be plugged into any application compatible with the OOPL. A program administrator or a system developer may incorporate the compare tool101into a desired application, and by programming the application to convert its documents or files into XML objects, the application may transmit to and receive from the compare tool101relevant documents for comparison. Accordingly, it is up to the program administrator to determine just how an application manipulates the Result XML object105once received from the compare tool101. Software components exist in the art that provide a means for transforming a document into an XML object, and one of ordinary skill will appreciate that the scope of the invention is not meant to be limited to any one means.

By processing documents in object form as opposed to flat files the compare tool101may compare documents from multiple sources and in different types, such as a text file, a spreadsheet, or a pictorial presentation, such as a PowerPoint™ presentation. Advantageously, the compare tool101uses fewer resources by being object oriented, because the relevant XML objects may be received from and transmitted to multiple applications without having to be converted to flat files or to their original form in order to be manipulated. The documents remain as XML objects throughout the comparison process.

FIG. 2illustrates a method for comparing XML documents according to a preferred embodiment of the present invention. The steps of the method need not be taken in the sequence illustrated, and some steps may be implemented essentially simultaneously. At step S201, the compare tool101receives a first XML object102and a second XML object103from an application, where logically the first received XML object102is to be compared against the second received XML object103. Elements and attributes present in the first XML object102that are not present in the second XML object103are considered by the compare tool101to be new elements and attributes added to the first XML object102. Elements and attributes present in the second XML object103but not present in the first XML object102are considered to be elements and attributes deleted from the first XML object102. Changes between corresponding elements and attributes in the first XML object102and the second XML object103are considered by the compare tool101to be modifications.

At step S202, the compare tool101receives a list104of elements and attributes to be excluded (exclusion list) from the comparison process, represented as a third XML object. During the comparison process, the compare tool101ignores changes in the elements and attributes specified in the exclusion list104. However, the compare tool101passes the excluded elements and attributes and their data to a Result XML object105so that no document content is left out of the processed result. Upon receipt of the first XML object102, the second XML object103, and the exclusion list104, the compare tool101is ready to perform the comparison process.

At step S203, the compare tool101opens the exclusion list104and stores the elements and attributes to be excluded in a computer-readable memory. The compare tool101then begins to traverse a tree structure of the first XML object102from the root node down to the lowest child node along a single path, or branch. The compare tool101then locates a corresponding root node in the second XML object103and traverses the structure of the second XML object103from the corresponding root node down to the lowest child node along a path corresponding to the path identified and traversed in the first XML object102. The compare tool101compares each node along the path in the first XML object102with each node along the corresponding path in the second XML object103. The compare tool101then traverses back up from the lowest child node to the most immediate parent node and then down to the next lowest child node and repeats this process until all nodes within both the first XML object102and the second XML object103have been traversed. An example of the compare tool101traversing an XML object according to a preferred embodiment of the present invention is discussed below in connection withFIG. 5.

As the compare tool101traverses both the first XML object102and the second XML object103, at step S203, the compare tool101generates the Result XML object105and stores results of the comparison in the Result XML object105, at step S204. As discussed above, the Result XML object105is a merged result of the first XML object102and the second XML object103and, thus, contains a superset of the elements and attributes of both the first and the second XML objects,102and103. When a change to an element or attribute in a node along the path being traversed is identified, the compare tool101annotates the change in the corresponding node in the Result XML object105. The compare tool101also annotates the change in the node in each parent node ascending from the particular node, all the way back to the root node. Thus, an application may review the root node of the Result XML object105to determine whether any changes exist between the first XML object102and the second XML object103as opposed to searching the entire Result XML object105.

The compare tool101identifies a change between corresponding nodes in the XML objects102and103as “modified.” The term “modified” is placed into the corresponding location in the Result XML object105, at step S204. If the compare tool101determines that a new element and/or attribute has been added to the first XML object102as compared to the second XML object103, the addition is identified as “inserted” in the corresponding location in the Result XML object105. If the compare tool101determines that an element or attribute which exists in the second XML object103is not present in the first XML object102, the compare tool101recognizes that the element or attribute has been deleted and identifies the deletion as “deleted” in the corresponding location in the Result XML object105. Accordingly, if the compare tool101determines that there is no change between corresponding elements and attributes in the first XML object102and the second XML object103, the corresponding location in the Result XML object105is annotated as “unchanged.” An example of a Result XML object105according to the preferred embodiment is discussed in greater detail below in connection withFIGS. 6 and 7.

Once the compare tool101completes the comparison process, at step S203, and generates the Result XML object105, at step S204, the compare tool101may transmit the Result XML object105, at step S205, in accordance with the application interfacing with the compare tool101. It is up to a program administrator to determine how the application should use the processed result from the compare tool101. The compare tool101then is ready to perform another comparison.

FIGS. 3 and 4illustrate a hierarchical structure, in programming language, of an XML object, similar to the first XML object102, the second XML object103, and the exclusion list104.FIG. 7illustrates a hierarchical structure, in programming language, of a processed result generated from the compare tool101, similar to the Result XML object105.

InFIG. 3, an XML object301includes a root element, batch303, with an attribute “version” and an attribute value of “2.2.” The batch303has two child elements: cds-trade304, which has an attribute “type” and an attribute value of “trade,” and status309, which has an element value of “matured.” The cds-trade304has four child elements: primary-id305, alt-id306, is-what-if307, and is-vanilla308. The primary-id305has an element value “558650” and an attribute “type” with an attribute value of “m3.” The alt-id306has an element value of “60170” and an attribute “type” with an attribute value of “internal.” The is-what-if307has an element value of “false,” and the is-vanilla308has an element value of “false” also.

Similar to the XML object301, an XML object302includes a root element, batch310, with an attribute “version” and an attribute value of “2.3” (similar to the batch303in the XML object301). The batch310has two child elements: cds-trade311, which has an attribute “type” and an attribute value of “trade” (similar to the cds-trade304in the XML object301) and version316, which has an element value of “2.0.” Similar to the XML object301, the cds-trade311has four child elements: primary-id312, alt-id313, is-what-if314, and is-vanilla315. The primary-id312has an element value “550789” and an attribute “type” with an attribute value of “m3.” The alt-id313has an element value of “52583” and an attribute “type” with an attribute value of “internal.” The is-what-if314has an element value of “false,” and the is-vanilla315has an element value of “true.”

Although the examples presented inFIGS. 3 and 4specify the XML version as “1.0,” one of ordinary skill will understand that the present invention is not limited to this specific version of XML, but may be adapted to all existing and future versions as they are developed and improved upon.

InFIG. 4, an exclusion list XML object400is provided for the compare tool101. The root element of the exclusion list400is non-confirmable401. All child nodes descending from the root element non-confirmable401are XML items to be excluded from the comparison process. Each node corresponds to one XML item and includes the following information: the name of the item, the type of the item, whether it is an element or an attribute, and the path of the item, which gives its location within the hierarchy of the XML object301,302.

InFIG. 4, the exclusion list400excludes the XML items: batch version402, cds-trade type403, alt-id404, and if-vanilla405from the comparison process. These excluded XML items correspond to the attributes of: the batch versions303and310, and the cds-trade types304and311; and the elements of: the alt-ids306and313, and the if-vanillas308and315in XML objects301and302, respectively.

As stated above, an XML item to be excluded is described by a name, a type and a path. The compare tool101interprets the excluded XML item402to mean that an attribute named “version,” which is located in the node “batch,” and an attribute value associated with this attribute are to be ignored during the comparison process. Similarly, the compare tool101interprets the exclusion XML item403to mean that an attribute named “type,” which is located in the node “batch/cds-trade,” and an attribute value associated with this attribute are to be ignored during the comparison process. The compare tool101interprets the exclusion XML items404and405to mean that an element named “alt-id” located in the node “batch/cds-trade/alt-id” and an element named “if-vanilla,” which is located in the node “batch/cds-trade/alt-id,” and their respective element values are to be ignored during the comparison process.

The compare tool101follows the exclusion rules displayed in Table 1, below:

Thus, if an item is to be excluded for the Result XML object105, if the item exists in the first XML object102but not the second XML object103, the compare tool101applies the top rule “New Item” and creates a corresponding item in the Result XML object105. The compare tool101then passes the data associated with the new item from the first XML object102to the corresponding item in the Result XML object105, and annotates the item in the Result XML object105as “unchanged.” If an excluded item exists in the second XML object103but not the first XML object102, the compare tool101applies the bottom rule “Deleted Item” and creates a corresponding item in the Result XML object105, but passes no item data to the item in the Result XML object105. However, if an excluded item has been modified from the second XML object103to the first XML object102, the compare tool101applies the middle rule “Changed Item” and creates a corresponding item in the Result XML object105. Similar to the rule “New Item,” the compare tool101passes the item and its associated data from the first XML object102and annotates the item as “unchanged” even though the item actually has changed between the first XML object102and the second XML object103. Thus, the exclusion list104allows a user to ignore irrelevant changes between documents and focus on the changes that are relevant.

FIG. 5illustrates the comparison process as performed on a hierarchical or “tree” structure of an XML object. Accordingly, an XML object500and an XML object501correspond to the XML objects301and302, respectively. Thus, nodes502through508in the XML object500correspond to the elements and attributes303through309, respectively, in the XML object301inFIG. 3. Similarly, nodes509through515in the XML object501correspond to the elements and attributes310through316, respectively, in the XML object302inFIG. 3.

As discussed above, the root element, or root node, of both the XML objects500and501are the batch nodes501and509, respectively. In the XML object500, the batch node502has two child nodes, cds-trade503and status508. The status508has no child nodes. However, the cds-trade503has four child nodes: primary-id504, alt-id505, is-what-if506, and is-vanilla507. The data associated with each node is displayed accordingly. Similarly, in the XML object501, the batch node509has two child nodes: cds-trade510and version515. The version515has no child nodes. However, the cds-trade510has four child nodes: primary-id511, alt-id512, is-what-if513, and is-vanilla514.

InFIG. 5, arrows5.1through5.12illustrate the logic the compare tool101follows as it traverses the XML objects during the comparison process in accordance with a preferred embodiment of the present invention. As mentioned above, when the compare tool101traverses the first XML object, in this case, the XML object500, the compare tool101begins at the root node, the batch node502, and searches the second XML object, in this case, the XML object501, for a root node. The compare tool101determines that the batch node509is the root node of the XML object501. Simultaneously, the compare tool101begins to generate a Result XML object600, as shown inFIG. 6, and creates a root node601. The compare tool101determines that both root nodes, i.e., the batch nodes502and509contain a single attribute “version” and an attribute value.

In a straight comparison, the compare tool101compares the batch node502with the batch node509and determines that there has been a change from the XML object501to the XML object500in that the attribute value “2.3” has changed to “2.2.” Within the root node601, the compare tool101indicates that a change has occurred by using the annotation “modified.” The compare tool101then carries the node data from the first XML object, i.e., the XML object500, and assigns it to the root node, the batch node601, as indicated by the “2.2” in the batch node601. Again, this is what occurs with a straight comparison where no exclusion list is involved.

However, by applying the exclusion list400ofFIG. 4, the compare tool101recognizes that the attribute “version” in a node “batch” is to be ignored during the comparison process, as shown at402. In accordance with the exclusion rules in Table 1, the compare tool101ignores the change in version numbers, generates a “batch” node601in the Result XML object600, and passes the node data from the XML object500, i.e., “version=2.2.” The compare tool101also annotates the batch node601as “unchanged.” However, this annotation may change as the comparison process progresses.

The compare tool101then traverses along a path5.1from the root node, i.e., the batch502, to the first descending child node, i.e., the cds-trade node503, in the XML object500. The compare tool101then traverses the XML object501along a path similar to5.1from the root node, i.e., the batch node509, to the first descending child node, which happens to be the cds-trade node510. The compare tool101determines that the cds-trade nodes503and510contain an attribute “type” with the same attribute value “Trade.” The compare tool101creates a cds-trade node602in the Result XML object600. In a straight comparison, the compare tool101would annotate the cds-trade node602in the Result XML object600as “unchanged” and pass the attribute value “Trade” to the cds-trade node602. However, with the exclusion list400, the compare tool101recognizes that an attribute “type” in a node “cds-trade” is to be ignored during the comparison process, as shown at403. The end result is the same: the compare tool101annotates the cds-trade node602as “unchanged” and passes the attribute value from the first XML object, i.e., the XML object500, which is “trade,” in accordance with the exclusion rules in Table 1. Although there is no change between the cds-trade node503in the XML object500and the cds-trade node510in the XML object501, if there had been a change, the compare tool101would have ignored it.

The compare tool101then determines that the cds-trade nodes503,510are not the lowest child node descending from the root node, i.e., the batch nodes502,509. Thus, the compare tool101traverses along a path5.2from the cds-trade node503in the XML object500to a descending child node, if one exists. In the XML object500, a child node descending from the cds-trade node503is the primary-id node504. The compare tool101traverses a path similar to5.2from the cds-trade node510in the XML object501and locates the first descending child node, i.e., the primary-id node511. The compare tool101reviews the exclusion list400and determines that neither elements nor attributes associated with a “primary-id” node are to be excluded from the comparison process. Thus, the compare tool101compares the elements and attributes of the primary-id nodes504and511and determines that both nodes contain an element with an element value, and an attribute “type” with an attribute value. The compare tool101determines that although there has been no change between the attribute and the attribute values in the primary-id nodes504and511, the element value has changed from “550789” in the primary-id node511to “558650” in the primary-id node504. The compare tool101creates a primary-id node603in the Result XML object600at a corresponding location, and annotates the primary-id node603as “modified.” The compare tool101passes data associated with the unchanged attribute as indicated by the line “type-unchanged=‘m3,’” and passes both the new element value “558650” from the XML object500, and the old element value “550789” from the XML object501. The compare tool101then begins to search for any child nodes descending from the primary-id nodes504and511, in the XML objects500and501, respectively.

InFIG. 5, the compare tool101determines that both the primary-id node504and the primary-id node511are the lowest child nodes along that path5.2in both the XML objects500and501, respectively. The compare tool101, therefore, traverses back up the path from the primary-id nodes504,511to the immediate parent node, i.e., the cds-trade nodes503,510, as shown at5.3. As discussed above, changes made in the child nodes are percolated back up the path to the root node. Thus, the compare tool101annotates the cds-trade node602in the Result XML object to reflect the change to the element value between the cds-trade nodes503and510. In the cds-trade node602, the compare tool101reflects the change made in the child primary-id nodes503and510by changing the annotation from “unchanged” to “modified.” However, the elements and attributes associated with the cds-trade node602remain unchanged.

The compare tool101then traverses along a path5.4to determine if the cds-trade nodes503,510have additional child nodes, in the XML objects500,501. Upon doing so, the compare tool101locates the next child node, which are the alt-id nodes505,512in the XML objects500,501, respectively, and determines that the alt-id nodes505,512contain an element value, an attribute “internal,” and an attribute value. The compare tool101then reviews the exclusion list400and determines that an element in a “alt-id” node is to be ignored during the comparison process, as shown at404. Thus, the compare tool101ignores the change in the element value from “52583” in the alt-id node512to “60170” in the alt-id node505. The compare tool101, however, compares the attribute “type” and attribute value in both the alt-id nodes505and512, and determines that no change has occurred. The compare tool101creates an alt-id node604in the Result XML object600at the proper location, and annotates the alt-id node604in the Result XML object600as “unchanged” The compare tool101passes the element and attribute data from the alt-id node505in the XML object500to the alt-id node604in the Result XML object600, in accordance with the exclusion rules in Table 1.

The compare tool101next determines that the alt-id nodes505,512in both the XML objects500and501are the lowest child nodes along the path5.4, and traverses the XML objects500and501along a path5.5back up to the immediate parent node, i.e., the cds-trade nodes503,510. The compare tool101then traverses the XML objects500and501to search for other child nodes descending from the cds-trade nodes503,510. In both the XML objects500and501, the next child nodes descending from the cds-trade nodes503,510are the is-what-if nodes506,513along a path5.6. The compare tool101determines that the is-what-if nodes506,513each contain a single element value. The compare tool101then reviews the exclusion list400and determines that an “is-what-if” node is not listed as an excluded XML item. Thus, the compare tool101compares the element value “false” of the is-what-if node506in the XML object500to the element value “false” of the is-what-if node513in the XML object501, and determines that no change has occurred. Accordingly, the compare tool101creates an is-what-if node605in the Result XML object600at the proper location, and annotates the is-what-if node605in the Result XML object600as “unchanged.” The compare tool101then passes the element value “false” to the is-what-if node605.

The compare tool101next determines that the is-what-if nodes506,513in the XML objects500,501, respectively, are the lowest child nodes along the path5.6, and traverses the XML objects500and501along a path5.7back up to the immediate parent nodes, i.e., the cds-trade nodes503,510. The compare tool101then traverses the XML objects500,501to search for other child nodes descending from the cds-trade nodes503,510. In both the XML objects500and501, the next child nodes descending from the cds-trade nodes503,510are the is-vanilla nodes507,514along a path5.8. The compare tool101determines that the is-vanilla nodes507,514each contain a single element value. The compare tool101then reviews the exclusion list400and determines that an element value of an “is-vanilla” node is to be excluded from the comparison process, as shown at405. Thus, the compare tool101ignores the fact that the element value of the if-vanilla nodes506,513has changed from “true” in the XML object501to “false” in the XML object500. The compare tool101creates an is-vanilla node606in the Result XML object600at the proper location, and annotates the if-vanilla node606in the Result XML object600as “unchanged.” The compare tool101passes the element value “false” from the XML object500, in accordance with the exclusion rules in Table 1.

The compare tool101next determines that the is-vanilla nodes507,514in both the XML objects500and501are the lowest child nodes along the path5.8, and traverses the XML objects500and501along a path5.9back up to the immediate parent nodes, the cds-trade nodes503,510. The compare tool101then traverses the XML objects500,501to search for other child nodes descending from the cds-trade nodes503,510. In both the XML objects500and501, no other child nodes descend from the cds-trade nodes503,510, and, thus, the compare tool101traverses along a path5.10back up to the root nodes, i.e., the batch node502,509. As discussed above, any changes made in child nodes descending from a parent node percolate up to the parent node. Thus, the change determined in the primary-id nodes504,511, which percolated to the cds-trade nodes503,510, now percolates to the root nodes, the batch nodes502,509. The compare tool101alters the annotation “unchanged” in the batch node601in the Result XML object600to “modified” to indicate the change. No other data within the batch node600changes, thus, an application viewing the Result XML object600recognizes that a modification has occurred in a child node descending from the root nodes, i.e., the batch nodes502,509.

The compare tool101then traverses the XML objects500and501to search for other child nodes descending from the batch nodes502,509. In the XML object500, the compare tool101locates a child node, the status node508, along a path5.11and determines that the status node508contains an element value “matured.” However, when the compare tool101traverses a similar path to5.11, the compare tool101locates a child node, the version node515, but no child node corresponding to the status node508. The compare tool reviews the exclusion list400and determines that both the status node508and the version node515are to be included in the comparison process. The compare tool101creates a status node607and a version node608in the Result XML object600. The compare tool then annotates the status node607as “inserted” and the version node608as “deleted” in the Result XML object600.

In accordance with the exclusion rules in Table 1, if the exclusion list400lists the version node515as an XML item to be excluded from the comparison process, the compare tool101would have created a version node607in the Result XML object600, but would not pass the element value “2.0,” because this information is irrelevant to the user. However, because the version node515is included in the comparison process, the compare tool101passes the element value “2.0” to the version node608in the Result XML object600.

At this point, the compare tool101traverses the XML objects500,501to determine if child nodes descend from either the status node508or the version node515. The compare tool101determines that both the status node508and the version node515are the lowest child nodes along the path5.11and traverses along a path5.12back up to the immediate parent nodes, i.e., the batch nodes502,509. The compare tool101then traverses the XML objects500,501to determine if other child nodes descend from the batch nodes502,509and finds none. Thus, the compare tool101determines that the no other nodes exist to process, and terminates the comparison process. The compare tool101prepares the Result XML object600for transmitting to one or more locations as instructed by the application interacting with the compare tool101, and transmits the Result XML object600accordingly.

FIG. 7illustrates the processed result, i.e., the Result XML object600, in a flat file format referred to as a Flat Result XML object700. In the Flat Result XML object700, XML items701through708correspond to the nodes601through608, respectively. Thus, the Flat Result XML object700is a complete merge of the two XML documents submitted for comparison, and all elements and attributes from the XML object500and the XML object501are produced in the Flat Result XML object600, regardless of whether an element and/or attribute were excluded from the comparison process. No content is lost between the two compared XML documents.

As discussed above, an alternate embodiment of the present invention includes a compare tool receiving a first XML object, a second XML object, and a third XML object representing an inclusion list of items to limit the comparison process to. This feature is useful when a user wants to determine whether only a few changes have occurred between two XML documents. Rather than produce an extensive exclusion list, the compare tool may accept a list of items such that the compare tool processes only those items and no other content within the XML documents. The comparison process utilizing the inclusion list follows the same steps shown inFIG. 2, and produces a processed Result XML object similar to that shown inFIGS. 6 and 7.

As will be appreciated, many different types of applications can utilize the features of the present invention. The inventive method may also be embodied on computer-executable code that is stored on a computer-readable medium, for example, a floppy disk, a hard drive, removable media, an optical memory, a magneto-optical memory, a RAM, a ROM, a flash memory, so-called “memory sticks,” and the like.