U.S. patent application number 10/999312 was filed with the patent office on 2006-06-15 for system and apparatus for software versioning.
This patent application is currently assigned to MICROSOFT CORPORATION. Invention is credited to Srinivasa R. Burugapalli.
Application Number | 20060130047 10/999312 |
Document ID | / |
Family ID | 36585590 |
Filed Date | 2006-06-15 |
United States Patent
Application |
20060130047 |
Kind Code |
A1 |
Burugapalli; Srinivasa R. |
June 15, 2006 |
System and apparatus for software versioning
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.
Inventors: |
Burugapalli; Srinivasa R.;
(Sammamish, WA) |
Correspondence
Address: |
MARSHALL, GERSTEIN & BORUN LLP (MICROSOFT)
233 SOUTH WACKER DRIVE
6300 SEARS TOWER
CHICAGO
IL
60606
US
|
Assignee: |
MICROSOFT CORPORATION
Redmond
WA
|
Family ID: |
36585590 |
Appl. No.: |
10/999312 |
Filed: |
November 30, 2004 |
Current U.S.
Class: |
717/170 |
Current CPC
Class: |
G06F 8/71 20130101 |
Class at
Publication: |
717/170 |
International
Class: |
G06F 9/44 20060101
G06F009/44 |
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: (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.
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; (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.
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.
Description
TECHNICAL FIELD
[0001] This patent relates generally to computer languages and more
particularly to a markup language used to exchange information.
BACKGROUND
[0002] 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.
[0003] 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.
[0004] 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.
[0005] 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
[0006] 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
[0007] FIG. 1 is a block diagram of a network interconnecting a
plurality of computing resources;
[0008] FIG. 2 is a block diagram of a computer that may be
connected to the network of FIG. 1;
[0009] FIG. 3 illustrates a flowchart of a software versioning
program;
[0010] FIGS. 4A-4C illustrate a method of using "XML diff" files
during operation of the XML versioning program of FIG. 3;
[0011] FIGS. 5A-5C illustrate a flowchart of a merging program used
by the XML versioning program of FIG. 3; and
[0012] FIGS. 6A-6D illustrate various application forms generated
by XML applications illustrating use of the XML versioning program
of FIG. 3.
DESCRIPTION
[0013] 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.
[0014] 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. .sctn. 112, sixth paragraph.
[0015] Network
[0016] 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.
[0017] Computer
[0018] 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.
[0019] 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.
[0020] 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.
[0021] 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.
[0022] 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.
[0023] 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.
[0024] 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.
[0025] XML Versioning System
[0026] 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.
[0027] 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.
[0028] 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).
[0029] 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.
[0030] 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.
[0031] 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.
[0032] 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.
[0033] 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.
[0034] 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.
[0035] 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.sup.th version of the
XML application 243. Specifically, the n-1.sup.th version of the
XML application 243 is further customized to generate a customized
n-1.sup.th version 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.sup.th version of the XML application 243 may
generate the customized nth version of the XML application 249.
[0036] 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.
[0037] 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.
[0038] 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.
[0039] 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.
[0040] 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.
[0041] 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.
[0042] 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.
[0043] 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.
[0044] 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.
[0045] 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.
[0046] 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.
[0047] 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.
[0048] 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."
[0049] 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.
[0050] 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.
[0051] 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.
[0052] 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.
* * * * *