US20060130047A1

US20060130047A1 - System and apparatus for software versioning

Info

Publication number: US20060130047A1
Application number: US10/999,312
Authority: US
Inventors: Srinivasa Burugapalli
Original assignee: Microsoft Corp
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2004-11-30
Filing date: 2004-11-30
Publication date: 2006-06-15
Also published as: US20060294506A1; US7984424B2

Abstract

An extensible markup language (XML) versioning system allows versioning an XML based application software so that customizations made to an early version of the application software can be easily incorporated into the later version of the application software. The XML versioning system identifies XML semantic blocks in a customized early version of an application software to determine areas including customization metadata, defines the differences between the customized early version of an application software and a later revision of the application software in the determined areas, and provides a procedure to integrate the customization metadata into the later version of the application software.

Description

TECHNICAL FIELD

This patent relates generally to computer languages and more particularly to a markup language used to exchange information.

BACKGROUND

Over the past decade, the world wide web (web) has become an extremely popular vehicle for information exchange and electronic commerce over the Internet. The web uses various markup languages such as hypertext markup language (HTML), extensible markup language (XML), etc., to communicate information over the Internet. Among these languages, the XML has become the de-facto metadata language for describing application components such as forms, flows, schemas, and the like.
XML is a simple, very flexible text format derived from standard generalized markup language (SGML) protocol. Originally designed to meet the challenges of large-scale electronic publishing, XML is also playing an especially important role in the exchange of a wide variety of data on the web and elsewhere. Unlike HTML, XML is meant for storing data, not just for displaying the data. A number of software development companies provide a number of different application software using XML. Generally, software development companies provide the source code of the application software to users and the users often customize the application software to their own needs. On the other hand the software development companies continuously release updated versions of the application software with new features and capabilities. These simultaneous updating of application software, by the end users as well as by the software development company poses a problem in carrying the user updates from one version to next version of the application software release.
This is particularly true in the case of XML based applications. As XML is a preferred markup language for designing electronic commerce, each of the various user companies have different needs in terms of forms, databases, etc., provided by the applications. For example, a generic restaurant management software provided by a software development company may be customized by a client restaurant in a particular market to conform more closely to its local business needs. However, when the software development company releases the next version of the generic restaurant management software, the customizations made by the client restaurant will generally not be incorporated in the new version, making it necessary for the client to again make modifications to the newer version of the restaurant management software. Therefore, there is a need to provide an XML versioning system that allows users of XML application software to carry customizations from one version of the application software to the next.
For applications designed using XML, the customizations are generally described in the application file by metadata, which has to be separated from the XML semantic blocks. Current software versioning system that work with traditional programming languages work on text strings and analyze each text string at a time. However, for XML based applications, sometimes, the entire application may be stored in a single text line, which makes software versioning overly cumbersome and in some cases almost impossible.

SUMMARY

An XML versioning system allows versioning an extensible markup language (XML) based application software so that customizations made to an early version of the application software can be easily incorporated into the later version of the application software. The XML versioning system identifies XML semantic blocks in a customized early version of an application software to determine areas including customization metadata, defines the differences between the customized early version of an application software and a later revision of the application software in the determined areas, and provides a procedure to integrate the customization metadata into the later version of the application software.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a block diagram of a network interconnecting a plurality of computing resources;
FIG. 2 is a block diagram of a computer that may be connected to the network of FIG. 1;
FIG. 3 illustrates a flowchart of a software versioning program;
FIGS. 4A-4C illustrate a method of using “XML diff” files during operation of the XML versioning program of FIG. 3;
FIGS. 5A-5C illustrate a flowchart of a merging program used by the XML versioning program of FIG. 3; and
FIGS. 6A-6D illustrate various application forms generated by XML applications illustrating use of the XML versioning program of FIG. 3.

DESCRIPTION

Although the following text sets forth a detailed description of numerous different embodiments, it should be understood that the legal scope of the description is defined by the words of the claims set forth at the end of this patent. The detailed description is to be construed as exemplary only and does not describe every possible embodiment since describing every possible embodiment would be impractical, if not impossible. Numerous alternative embodiments could be implemented, using either current technology or technology developed after the filing date of this patent, which would still fall within the scope of the claims defining the invention.
It should also be understood that, unless a term is expressly defined in this patent using the sentence “As used herein, the term ‘______’ is hereby defined to mean . . . ” or a similar sentence, there is no intent to limit the meaning of that term, either expressly or by implication, beyond its plain or ordinary meaning, and such term should not be interpreted to be limited in scope based on any statement made in any section of this patent (other than the language of the claims). To the extent that any term recited in the claims at the end of this patent is referred to in this patent in a manner consistent with a single meaning, that is done for sake of clarity only so as to not confuse the reader, and it is not intended that such claim term by limited, by implication or otherwise, to that single meaning. Finally, unless a claim element is defined by reciting the word “means” and a function without the recital of any structure, it is not intended that the scope of any claim element be interpreted based on the application of 35 U.S.C. § 112, sixth paragraph.
Network
FIG. 1 illustrates a network 10 that may be used to implement an XML versioning system described herein. The network 10 may be the Internet, a virtual private network (VPN), or any other network that allows one or more computers, communication devices, databases, etc., to be communicatively connected to each other. The network 10 may be connected to a personal computer 12 and a computer terminal 14 via an Ethernet 16 and a router 18, and a landline 20. On the other hand, the network 10 may wirelessly connected to a laptop computer 22 and a personal data assistant 24 via a wireless communication station 26 and a wireless link 28. Similarly, a server 30 may be connected to the network 10 using a communication link 32 and a mainframe 34 may be connected to the network 10 using another communication link 36. As it will be described below in further detail, one or more components of the dynamic software provisioning system may be stored and operated on any of the various devices connected to the network 10.
Computer
FIG. 2 illustrates a computing device in the form of a computer 110 that may be connected to the network 10 and used to implement one or more components of the dynamic software provisioning system. Components of the computer 110 may include, but are not limited to a processing unit 120, a system memory 130, and a system bus 121 that couples various system components including the system memory to the processing unit 120. The system bus 121 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus.
Computer 110 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 110 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by computer 110. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency, infrared and other wireless media. Combinations of the any of the above should also be included within the scope of computer readable media.
The system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 132. A basic input/output system 133 (BIOS), containing the basic routines that help to transfer information between elements within computer 110, such as during start-up, is typically stored in ROM 131. RAM 132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 120. By way of example, and not limitation, FIG. 1 illustrates operating system 134, application programs 135, other program modules 136, and program data 137.
The computer 110 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only, FIG. 1 illustrates a hard disk drive 140 that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive 151 that reads from or writes to a removable, nonvolatile magnetic disk 152, and an optical disk drive 155 that reads from or writes to a removable, nonvolatile optical disk 156 such as a CD ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like. The hard disk drive 141 is typically connected to the system bus 121 through a non-removable memory interface such as interface 140, and magnetic disk drive 151 and optical disk drive 155 are typically connected to the system bus 121 by a removable memory interface, such as interface 150.
The drives and their associated computer storage media discussed above and illustrated in FIG. 1, provide storage of computer readable instructions, data structures, program modules and other data for the computer 110. In FIG. 1, for example, hard disk drive 141 is illustrated as storing operating system 144, application programs 145, other program modules 146, and program data 147. Note that these components can either be the same as or different from operating system 134, application programs 135, other program modules 136, and program data 137. Operating system 144, application programs 145, other program modules 146, and program data 147 are given different numbers here to illustrate that, at a minimum, they are different copies. A user may enter commands and information into the computer 20 through input devices such as a keyboard 162 and pointing device 161, commonly referred to as a mouse, trackball or touch pad. Other input devices (not shown) may includea microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 120 through a user input interface 160 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB). A monitor 191 or other type of display device is also connected to the system bus 121 via an interface, such as a video interface 190. In addition to the monitor, computers may also include other peripheral output devices such as speakers 197 and printer 196, which may be connected through an output peripheral interface 190.
The computer 110 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 180. The remote computer 180 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 110, although only a memory storage device 181 has been illustrated in FIG. 1. The logical connections depicted in FIG. 1 include a local area network (LAN) 171 and a wide area network (WAN) 173, but may also include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.
When used in a LAN networking environment, the computer 110 is connected to the LAN 171 through a network interface or adapter 170. When used in a WAN networking environment, the computer 110 typically includes a modem 172 or other means for establishing communications over the WAN 173, such as the Internet. The modem 172, which may be internal or external, may be connected to the system bus 121 via the user input interface 160, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 110, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation, FIG. 1 illustrates remote application programs 185 as residing on memory device 181. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.
XML Versioning System
FIG. 3 illustrates a flowchart of a software versioning program (SVP) 200 that may be implemented using the computer 110 of FIG. 2. Generally, the SVP 200 may be used to version a software used on any of various computing devices 12, 14, etc., connected to the network 10 of FIG. 1. At a block 202, the SVP 200 analyzes an XML software application running on the computer 110 to determine if there is any customization metadata that exists in the software application. To determine the existence of any customization metadata, the SVP 200 may apply an “XML diff” utility program on a particular software application running on the computer 110 and the original version of the particular software application.
Generally an XML diff utility determines difference between two XML documents by comparing an original XML document with a modified version of the XML document. The XML diff utility generates an output that identifies differences in the modified XML document and the original version of the document at various nodes. The output generated by applying the XML diff utility may be in XML diff language (XDL), which describes differences between two XML documents. An output of XML diff utility is also known as XDL diffgram or just diffgram, and is a structured tree of changes that should be applied to various nodes of the original XML document in order to get the modified XML document.
After analyzing the XML software application, at a block 204, the SVP 200 may determine if any customization has been made to the XML software application. If it is determined that no customization has been made to the XML software application, as illustrated by a block 206, no versioning may be required. However, if there has been any customization to the XML software application, at a block 208 the SVP 200 may generate and save a customization diff file (CDF).
The customization diff file may include an XDL namespace definition, a hash value of the original XML application, which can be used for verification that the original XML application has not been altered after a diff was performed, list of various options selected when the customization diff file was generated and various node operations specifying the changes that should be applied to various nodes of the original XML application in order to get the modified XML application. Various nodes in the customization diff file may be identified by the prefix xd, and may represent operations including a node operation, a change operation, a remove operation and an add operation. The functioning of an XML diff utility and the representation of an XDL file are well known to those of ordinary skill in the art and therefore are not described in further detail herein.
After generating the customization diff file, at a block 210, the SVP 200 may apply the XML diff utility to a later version of the XML application program to generate a versioning diff file (VDF), where the versioning diff file identifies various operations that should be performed on the original XML application to get the later version of the XML application. Again the versioning diff file may include various xd nodes identifying operations including a node operation, a change operation, a remove operation and an add operation.
Subsequently, at a block 212 the SVP 200 analyzes the customization diff file and the versioning diff file to generate a merge file, which enumerates various operations that should be performed on the original XML application to generate a later version of the XML application including various modifications that may be made by a user on the original XML application. One of ordinary skill in the art would appreciate that the operation of merging the customization diff file and the versioning diff file can be highly complex due to numerous differences between the original XML application, the customized XML application and the later version of the XML application. For example, a user may be have modified a particular element from the original XML application and the later version of the XML application may also have altered or moved that particular element, therefore, the merging operation may have to reconcile such multiple operations on various elements. The merging of the customization diff file and the versioning diff file to obtain the merged element that may be used to generate a difference file between the original XML document and the later version of the XML documents with the customizations is illustrated in further detail in FIGS. 5A-5C.
Finally, at a block 214, the SVP 200 applies the merge file on the original XML application to generate a later version of the XML application including various modifications that may be made by a user on the original XML application.
FIGS. 4A and 4B illustrate block diagrams 220 and 235 describing an implementation algorithm used in merging the customization diff file and the versioning diff file. Specifically, in FIG. 4A, assume that 222 is the original XML application, 224 is the later version of the XML application and 226 is the customized version of the XML application. The customization diff file provides the difference 228 between the original XML application 222 and the customized XML application 226, whereas the versioning diff file provides the difference 230 between the original XML application 222 and the later version 224 of the XML application. As specified in the block diagram 235, the VSP 200 merges the differences 228 and 230 to generate a merged file in a manner such that application of the differences 232 specified by the merged file to the original XML application 222 may result in generating the customized later version of the XML application 234.
On the other hand, FIG. 4C illustrates block diagrams 236 describing how the algorithm used in merging a customization diff file and a versioning diff file described above may be extended to several versions and several layers of customization on an XML file. Specifically, in FIG. 4C, assume that once the customized second version of the XML application 234 is obtained, a third version of the XML application 237 is developed. At the same time assume that the user has further customized the customized second version of the XML application 234 to get a customized XML application 238. In this case, to obtain a third version of customized XML application, one can generate a second customization diff file 239, a second versioning diff file 240, and merge these two diff files to generate a merged diff file 241, wherein the application of the merged diff file 241 on the customized second version of the XML application 234 will provide us a customized third version of the XML application 242.
The above process of generating a customized later version of an XML application can be generalized as further shown in FIG. 4C by performing the above steps on an n-1^thversion of the XML application 243. Specifically, the n-1^thversion of the XML application 243 is further customized to generate a customized n-1^thversion of the XML application 244, whereas the later version of the XML application is denoted by an XML application file 245. One can generate a customization diff file 246 and a versioning diff file 247 as well as a merged diff file 248 as specified above. Subsequently, application of the merged diff file 248 on the n-1^thversion of the XML application 243 may generate the customized nth version of the XML application 249.
Now referring to FIGS. 5A-5C, a merging program 250 illustrates combining the customization diff file and the versioning diff file to generate a merged file with the combined differences 232. At a block 252, the merging program 250 may analyze a current node in the versioning diff file. According to XDL namespace definition a node in an XDL file may represent a diff operation by using a prefix of xd. Thus the merging program 250 may identify the diff operations in the versioning diff file by looking for nodes having the prefix xd. At a block 254, the merging program 250 determines whether the diff operation specified by the current versioning diff file node is an add operation specifying addition of an element to the XML file. Because an add operation in the versioning diff file represents newly added components of the later version of the XML application, these operations should also be included in generating the customized later version of the XML application. Therefore, if the merging program 20 determines the operation specified by the current versioning diff file node to be an add operation, at a block 256, that add operation is added into the merge file.
If the diff operation of the versioning diff file is not an add operation, at a block 258 the merging program 250 analyzes the customization diff file to find a matching customization diff file node with a sequence identification matching the current node in the versioning diff file. If no matching customization diff file node is found, at a block 260 the merging program 250 determines if there are any additional nodes in the versioning diff file that need to be processed. If no additional node is found, the merging program 250 ends. However, if an additional node is found in the versioning diff file, a block 262 may replace the current node with the additional node, analyze the operation specified by the current node and transfer control back to the node 254.
If the merging program 250 finds a matching customization diff file node, at a block 264, the merging program 250 determines the operation type specified by that matching customization diff file node. Just as in the case of the versioning diff file, each node in the customization diff file may also specify any of various operations including a node operation, an add operation, a change operation or a remove operation. If it is determined at the block 264 that the operation specified by the matching customization diff file node is an add operation, at a block 266, the merging program 150 may merge the customization diff file add operation into the merged file. Thus, any add operation specified by a user into the customized XML application will be preserved into the customized later version of the XML application.
Subsequently, at a block 268, the merging program 250 may determine if the operation specified by the current versioning diff file node is one of a node operation, a change operation and a remove operation, and based on the determination, transfers control to one of blocks 270, 272 and 274, respectively.
The block 270, which receives control if the current versioning diff file node specifies a node operation, may determine if the matching customization diff file node specifies one of a node operation, a change operation and a remove operation. If the matching customization diff file node specifies a change operation, a block 276 may merge various operations specified by each of the child node of the versioning diff file node into the merge file. The block 276 may ensure that if the matching customization diff file node specifies a change operation, that change operation is performed on each of the child node of that matching customization diff file node, thus ensuring that if any child nodes were added in the later version of the XML application, they carry the customization specified by the matching customization diff file node. Similarly, if the matching customization diff file node specifies a node operation, a block 278 may also merge various operations specified by each of the child node of the versioning diff file node into the merge file.
On the other hand, if the matching customization diff file node specifies a remove operation, a block 280 may determine if the remove operation also specifies removing a sub-tree, meaning that the remove operation needs to be performed on each of the child nodes. This may be the case if, during customization, the user has decided to remove all the child nodes of a given node. In this situation, a block 282 may ignore the operation specified by the current versioning diff file node, in this case a node operation, for each of the child nodes, as these child nodes are to be removed according to the matching customization diff file node. If there is no specification for removing the sub-tree, at a block 284, each of the child node operations of the matching customization diff file node may be merged into the merge file.
Now referring to the FIG. 5B, the block 272, which receives control if a versioning diff file node specifies a change operation, may determine if the matching customization diff file node specifies one of a node operation, a change operation and a remove operation. If the matching customization diff file node specifies a change operation, a block 286 may merge the change operation into the merge file. On the other hand if the matching customization diff file node specifies a node operation, a block 288 may convert that node operation to a change operation as specified by the current versioning diff file node. Changing each node operation of matching customization diff file node into a change operation as specified by the current versioning diff file node ensures that a change made in the later version. of the XML application is carried onto the later version of the customized XML application.
On the other hand, if it is determined that the matching customization diff file node specifies a remove operation, a block 290 may determine if the remove operation also specifies removing a sub-tree, meaning that the remove operation needs to be performed on each of the child nodes. This may be the case if, during customization, the user has decided to remove all the child nodes of a given node. In this situation, a block 292 may ignore the operation specified by the current versioning diff file node, in this case a node operation, for each of the child nodes, as these nodes are to be removed according to the matching customization diff file node. If there is no specification for removing the sub-tree, at a block 294, the merging program 250 may determine if the matching customization diff file node has any children. If the matching customization diff file node does not have any children, as specified by a block 296, the merging program 250 may ignore the operation specified by the versioning diff file node, as there are no child nodes to which the versioning diff file node operation needs to be applied to. If the matching customization diff file node has children, as specified by a block 298, the operation specified by the current versioning diff file node, in this case a change operation, may be applied to each of the child nodes of the matching customization diff file node and the matching customization diff file nodes may be merged into the merge file.
Now referring to the FIG. 5C, the block 274 may determine if the matching customization diff file node specifies one of a node operation, a change operation and a remove operation. If it is determined that the matching customization diff file node is a node operation, a block 300 may convert the matching customization diff file node operation to a remove operation as specified by the current versioning diff file node and merge the converted customization diff file node into to the merge file. This ensures that any remove operation necessary to get the later version of the XML application is included in the merge file.
If it is determined that the matching customization diff file node is a change operation, a block 302 may convert the matching customization diff file node operation to a remove operation as specified by the current versioning diff file node and merge the converted customization diff file node into to the merge file. Again, this ensures that any remove operation necessary to get the later version of the XML application is included in the merge file. Note that if, during customization, a user had performed a change operation on an element of the XML application and if the later version of the XML application removes that element, the change to that element will be lost in the customized later version of the XML application.
If it is determined that the matching customization diff file node is a remove operation, a block 304 may determine if the current versioning diff file node specifying the remove operation specifies removing a sub-tree and blocks 306 and 308 may determine if the matching customization diff file node remove operation also specifies removing a sub-tree. If both the current versioning diff file node and the matching customization diff file node specify removing a sub-tree, at a block 310, the merging program 250 may remove all children nodes to the matching customization diff file node, thus removing the duplicate remove operations. On the other hand, if neither of the versioning diff file node and the matching customization diff file node specifies removing a sub-tree, at a block 312, the merging program 250 may merge each of the child nodes of the matching customization diff file node without any change to the merge file. Finally, if only one of the current versioning diff file node and the matching customization diff file node specifies removing a sub-tree, as specified by a block 314, the merging program 250 may ignore the operation specified by the versioning diff file node.
Having described the operation of the merging program 250 above, application of the merging program 250 is described below in further detail with respect to an XML form application. Specifically, FIG. 6A illustrates an original form 350 used to receive certain customer data. A person of ordinary skill in the art would recognize that various fields such as name, description, actual revenue, etc., may be specified by various elements in an original XML form application file.
FIG. 6B illustrates a customized version form 352 of the original form 350, where the user has added two new fields, namely, status and priority, modified title of one of the fields from “actual close date” to “closed date,” and removed a field “stage.” FIG. 6C illustrates a second version form 354 of the XML form application, where the stage and the probability fields have been removed, a new field called profit is added and the title of an “actual revenue” field has been changed to “revenue.”
The XML diff utility may be applied to the original XML application file that generated the original form 350 and a customized XML application file that generates the customized version form 352 to generate a customization diff file. Similarly, the XML diff utility may be also applied to the original XML application file that generated the original form 350 and a second version XML application file that generates the second version form 354 to generate a versioning diff file. Subsequently the merging program 250 may be used to generate a merged diff file that can be used to generate a merged form 356, as specified in FIG. 6D.
As seen in the merged form 356, the customizations made by the user, namely addition of the “status” and “priority” fields, removal of “stage” filed, and change of “actual close date” to “closed date” are carried over onto the merged form 356. Similarly, the changes introduced in the second version form 356, namely removing of the “stage” and “priority” fields, addition of the “profit” field and changing of “actual revenue” to “revenue” are also carried forward to the merged form 356.
Although the forgoing text sets forth a detailed description of numerous different embodiments of the invention, it should be understood that the scope of the invention is defined by the words of the claims set forth at the end of this patent. The detailed description is to be construed as exemplary only and does not describe every possible embodiment of the invention because describing every possible embodiment would be impractical, if not impossible. Numerous alternative embodiments could be implemented, using either current technology or technology developed after the filing date of this patent, which would still fall within the scope of the claims defining the invention.
Thus, many modifications and variations may be made in the techniques and structures described and illustrated herein without departing from the spirit and scope of the present invention. Accordingly, it should be understood that the methods and apparatus described herein are illustrative only and are not limiting upon the scope of the invention.

Claims

1. A method of versioning an XML document, comprising:

(a) generating a customization difference file specifying customization operations to be performed on an XML document;

(b) generating a versioning difference file specifying versioning operations to be performed on the XML document; and

(c) merging the customization difference file and the versioning difference file to generate a merged difference file.

2. A method of claim 1, further comprising operating a number of difference operations specified in the merged difference file on the XML document.

3. A method of claim 2, wherein the XML document is an XML source file for at least one of: (1) a business process; (2) a business application; and (3) a business form.

4. A method of claim 1, wherein each of the customization difference file, the versioning difference file and the merged difference file include a number of difference operations including at least one of: (1) a node operation; (2) an add operation; (3) a change operation and (4) a remove operation.

5. A method of claim 1, wherein merging the customization difference file and the versioning difference file further comprises reconciling a first difference operation in the customization difference file with a second difference operation in the versioning difference file.

6. A method of claim 1, wherein the XML document is an XML application for displaying a form.

7. A method of claim 1, wherein the XML document is stored in a single text line.

8. A method of claim 1, wherein the customization difference file and the versioning difference file are generated by an XML diff utility program.

9. A method of claim 1, wherein generating the customization difference file includes the steps of:

(a) identifying a semantic block in the XML document;

(b) determining a first section in the XML document using the semantic block, the first section having customization metadata;

(c) determining a second section in a customized XML document corresponding to the first section; and

(d) determining differences between the first section and the second section.

10. A method of claim 9, wherein the semantic block in the XML document is at least one of: (1) an element; (2) a processing instruction; (3) a CDATA section; (4) a comment and (5) a document type definition (DTD).

11. A method of claim 1, further comprising applying the merged difference file on the XML document using an XML patch program.

12. A computer-readable medium having computer-executable instructions for performing steps comprising:

13. A computer readable medium of claim 12, further comprising computer-executable instructions for operating a number of difference operations specified in the merged difference file on the XML document.

14. A computer readable medium of claim 12, wherein each of the customization difference file, the versioning difference file and the merged difference file include a number of difference operations including at least one of: (1) a node operation; (2) an add operation; (3) a change operation and (4) a remove operation.

15. A computer readable medium of claim 12, wherein merging the customization difference file and the versioning difference file further comprises reconciling a first difference operation in the customization difference file with a second difference operation in the versioning difference file.

16. A computer readable medium of claim 12, wherein the XML document is an XML application for displaying a form.

17. A computer readable medium of claim 12, wherein the XML document is stored in a single text line.

18. A computer readable medium of claim 12, wherein the customization difference file and the versioning difference file are generated by an XML diff utility program.

19. A computer readable medium of claim 12, wherein generating the customization difference file includes the steps of:

(a) identifying a semantic block in the XML document;

(d) determining differences between the first section and the second section.

20. A computer readable medium of claim 19, wherein the semantic block in the XML document is at least one of: (1) an element; (2) a processing instruction; (3) a CDATA section; (4) a comment and (5) a document type definition (DTD).

21. A computer readable medium of claim 12, further comprising computer-executable instructions for applying the merged difference file on the XML document using an XML patch program.

22. A system for versioning an XML document, comprising:

a first apparatus adapted to generate a customization difference file specifying customization operations to be performed on an XML document;

a second apparatus adapted to generate a versioning difference file specifying versioning operations to be performed on the XML document; and

a third apparatus adapted to merge the customization difference file and the versioning difference file to generate a merged difference file.

23. A system of claim 22, further comprising a fourth apparatus adapted to apply the merged difference file on the XML document using an XML patch program.