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  
       [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. § 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 th  version of the XML application  243 . Specifically, the n-1 th  version of the XML application  243  is further customized to generate a customized n-1 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 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.