US20040194016A1 - Dynamic data migration for structured markup language schema changes - Google Patents
Dynamic data migration for structured markup language schema changes Download PDFInfo
- Publication number
- US20040194016A1 US20040194016A1 US10/403,342 US40334203A US2004194016A1 US 20040194016 A1 US20040194016 A1 US 20040194016A1 US 40334203 A US40334203 A US 40334203A US 2004194016 A1 US2004194016 A1 US 2004194016A1
- Authority
- US
- United States
- Prior art keywords
- source file
- language specification
- structured language
- contents
- structured
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/10—Text processing
- G06F40/12—Use of codes for handling textual entities
- G06F40/151—Transformation
- G06F40/16—Automatic learning of transformation rules, e.g. from examples
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/10—Text processing
- G06F40/12—Use of codes for handling textual entities
- G06F40/14—Tree-structured documents
- G06F40/143—Markup, e.g. Standard Generalized Markup Language [SGML] or Document Type Definition [DTD]
Definitions
- the present invention relates to computer software, and deals more particularly with techniques for programmatically migrating structured documents created according to one version of a schema such that those structured documents may adhere to a revised version of the schema (or schema equivalent, alternatively).
- XML Extensible Markup Language
- WML Wireless Markup Language
- WML Wireless Markup Language
- WML VoiceXML
- MathML MathML
- a Document Type Definition (“DTD”) was used for specifying the grammar for a particular structured document (or set of documents). That is, a DTD specifies the set of allowable markup tags, where this set indicates the permissible elements and attributes to be used in the document(s).
- a “schema” is commonly used instead of a DTD.
- a schema contains information similar to that in a DTD, but is much more functionally rich, and attempts to specify more requirements for the structured documents which adhere to it.
- W3C World Wide Web Consortium
- XML Schemas express shared vocabularies and allow machines to carry out rules made by people. They provide a means for defining the structure, content and semantics of XML documents.”. Documents discussing schemas may be found in many places, including the W3C Web site. Today, schemas are well known in the art.
- An object of the present invention is to provide techniques for programmatically migrating structured documents created according to one version of a schema such that those structured documents may adhere to a revised version of the schema.
- Another object of the present invention is to provide techniques for dynamically migrating data encoded in a structured markup language such that the data aligns with a revised data definition.
- a further object of the present invention is to provide techniques for programmatically attempting to repair structured document content that fails a validation process.
- this technique comprises: recording one or more changes that are made to a first structured language specification when creating a second structured language specification; and using the recorded changes to programmatically migrate contents of a source file encoded to adhere to the first structured language specification such that it adheres to the second structured language specification.
- the changes are recorded in a single location, and in particular, this single location is preferably a change file that is identified in, but physically separate from, the second structured language specification.
- the first structured language specification and the second structured language specification are preferably schemas (or schema equivalents).
- the recorded changes may represent one or more interim versions of the structured language specification.
- a subset of the changes will be the result of creating the interim version(s), and the remaining changes will reflect changing the final interim version to become the second structured language specification.
- the source file that is programmatically migrated may have been originally encoded to adhere to any of the interim structured language specifications (rather than the first structured language specification).
- the programmatic migration may be responsive to detecting a validation error when attempting to validate the contents of the source file (e.g., using a parser) against the second structured language specification, or it may be triggered in another way, including as a precursor to attempting such a validation.
- the programmatic migration may comprise revising the contents of the source file, an in-memory representation of the contents of the source file, and/or a copy of the contents of the source file.
- a user may be prompted before changing the contents of one or more of these files.
- the source file is preferably encoded in a structured markup language such as XML (or a derivative thereof), and the first and second structured language specifications then define allowable syntax for files encoded in this structured markup language.
- a structured markup language such as XML (or a derivative thereof)
- the present invention may also be used advantageously in methods of doing business, for example by providing dynamic data migration services for clients.
- This service may be provided under various revenue models, such as pay-per-use billing, monthly or other periodic billing, and so forth.
- FIG. 1 is a block diagram of a computer hardware environment in which the present invention may be practiced, according to the prior art
- FIG. 2 is a diagram of a networked computing environment in which the present invention may be practiced, according to the prior art
- FIGS. 3 and 4 illustrate components involved when validating structured documents according to the prior art and according to preferred embodiments of the present invention, respectively;
- FIGS. 5-7 provide flowcharts illustrating logic that may be used when implementing preferred embodiments of the present invention.
- FIGS. 8 and 9 (comprising FIGS. 8A and 8B, 9 A and 9 B) provide sample XML documents and their corresponding tree structures, and are used to illustrate operation of preferred embodiments;
- FIG. 10 depicts a first version of a sample schema that may be used when validating the XML documents in FIGS. 8A and 9A
- FIG. 11 depicts a modified version of this sample schema that may be used for validating the same documents
- FIG. 12 illustrates the general format of a sample schema change document, created according to preferred embodiments to record how a schema has been changed
- FIG. 13 provides a schema change document that records how the schema in FIG. 10 was changed to create the schema in FIG. 11;
- FIG. 14 illustrates a schema defining the allowable contents (i.e., grammar) of a schema change document, according to preferred embodiments.
- the present invention provides techniques for programmatically migrating structured documents created according to one version of a schema, such that those structured documents may adhere to a revised version of the schema.
- preferred embodiments of the present invention are described in terms of elements of XML documents defined according to an XML schema.
- inventive concepts disclosed herein may be adapted to elements encoded in other structured markup languages and/or which are defined using other definitional approaches (such as document type definitions, or “DTDs”).
- references herein to “XML” and “schema” are intended to encompass functionally similar languages and definitions.
- the present invention allows changes to be made to XML schemas without having to manually change all dependent XML files (and without having to search for the files that are dependent).
- many schema changes may be made that are of minor to moderate complexity, and such changes may be made rapidly and frequently throughout the development process.
- the dependent XML files can by revised programmatically, using knowledge of the particular schema changes that have been made. (This knowledge also enables determining whether any validation problems that arise are simply due to the schema changes, or instead signify an error in the document-producing logic.)
- FIG. 1 illustrates a representative computer hardware environment in which the present invention may be practiced.
- the environment of FIG. 1 comprises a representative computer workstation 10 , such as a personal computer, including related peripheral devices.
- the workstation 10 includes a microprocessor 12 and a bus 14 employed to connect and enable communication between the microprocessor 12 and the components of the workstation 10 in accordance with known techniques.
- the workstation 10 typically includes a user interface adapter 16 , which connects the microprocessor 12 via the bus 14 to one or more interface devices, such as a keyboard 18 , mouse 20 , and/or other interface devices 22 , which can be any user interface device, such as a touch sensitive screen, digitized entry pad, etc.
- the bus 14 also connects a display device 24 , such as an LCD screen or monitor, to the microprocessor 12 via a display adapter 26 .
- the bus 14 also connects the microprocessor 12 to memory 28 and long-term storage 30 which can include a hard drive, diskette drive, tape drive, etc.
- the workstation 10 may communicate with other computers or networks of computers, for example via a communications channel or modem 32 .
- the workstation 10 may communicate using a wireless interface at 32 , such as a cellular digital packet data (“CDPD”) card.
- CDPD digital packet data
- the workstation 10 may be associated with such other computers in a local area network (“LAN”) or a wide area network (“WAN”), or the workstation 10 can be a client in a client/server arrangement with another computer, etc. All of these configurations, as well as the appropriate communications hardware and software, are known in the art.
- FIG. 2 illustrates a data processing network 40 in which the present invention may be practiced.
- the data processing network 40 may include a plurality of individual networks, such as wireless network 42 and network 44 , each of which may include a plurality of individual workstations 10 .
- one or more LANs may be included (not shown), where a LAN may comprise a plurality of intelligent workstations coupled to a host processor.
- the networks 42 and 44 may also include mainframe computers or servers, such as a gateway computer 46 or application server 47 (which may access a data repository 48 ).
- a gateway computer 46 serves as a point of entry into each network 44 .
- the gateway 46 may be coupled to another network 42 by means of a communications link 50 a .
- the gateway 46 may also be directly (or indirectly) coupled to one or more workstations 10 using a communications link 50 b , 50 c .
- the gateway computer 46 may also be coupled 49 to a storage device (such as data repository 48 ).
- the gateway computer 46 may be implemented utilizing an Enterprise Systems Architecture/370TM available from the International Business Machines Corporation (“IBM®”), an Enterprise Systems Architecture/390® computer, etc.
- a midrange computer such as an Application System/400® (also known as an AS/400®) may be employed.
- Application System/400® also known as an AS/400®
- Enterprise Systems Architecture/370 is a trademark of IBM; “IBM”, “Enterprise Systems Architecture/390”, “Application System/400”, and “AS/400”are registered trademarks of IBM.
- the gateway computer 46 may be located a great geographic distance from the network 42 , and similarly, the workstations 10 may be located a substantial distance from the networks 42 and 44 .
- the network 42 may be located in California, while the gateway 46 may be located in Texas, and one or more of the workstations 10 may be located in Florida.
- the workstations 10 may connect to the wireless network 42 using a networking protocol such as the Transmission Control Protocol/Internet Protocol (“TCP/IP”) over a number of alternative connection media, such as cellular phone, radio frequency networks, satellite networks, etc.
- TCP/IP Transmission Control Protocol/Internet Protocol
- the wireless network 42 preferably connects to the gateway 46 using a network connection 50 a such as TCP or User Datagram Protocol (“UDP”) over IP, X.25, Frame Relay, Integrated Services Digital Network (“ISDN”), Public Switched Telephone Network (“PSTN”), etc.
- the workstations 10 may alternatively connect directly to the gateway 46 using dial connections 50 b or 50 c .
- the wireless network 42 and network 44 may connect to one or more other networks (not shown), in an analogous manner to that depicted in FIG. 2.
- the present invention is provided in software.
- software programming code which embodies the present invention is typically accessed by the microprocessor 12 of the workstation 10 or server 47 from long-term storage media 30 of some type, such as a CD-ROM drive or hard drive.
- the software programming code may be embodied on any of a variety of known media for use with a data processing system, such as a diskette, hard drive, or CD-ROM.
- the code may be distributed on such media, or may be distributed from the memory or storage of one computer system over a network of some type to other computer systems for use by such other systems (and their users).
- the programming code may be embodied in the memory 28 , and accessed by the microprocessor 12 using the bus 14 .
- the techniques and methods for embodying software programming code in memory, on physical media, and/or distributing software code via networks are well known and will not be further discussed herein.
- the computing environment in which the present invention may be used includes an Internet environment, an intranet environment, an extranet environment, or any other type of networking environment. These environments may be structured in various ways, including a client-server architecture or a multi-tiered architecture.
- the present invention may also be used in a disconnected (i.e., stand-alone) mode, for example where a user validates an XML file on a workstation, server, or other computing device without communicating across a computing network.
- FIG. 3 illustrates components involved when validating structured documents according to the prior art.
- the validation process 300 comprises supplying an XML source file 310 and an XML schema 320 to a component 330 that is referred to herein as a parser.
- a parser uses schema 320 to determine, inter alia, whether XML source file 310 is a valid document. Therefore, the terms “parse” and “validate” are used synonymously herein for purposes of describing the present invention.
- an output of the parsing process is a parsed document 340 (e.g., a stream of tokens and/or a document object model or “DOM” tree). If the source file 310 is not valid, then an output of the parsing process is typically a report of the validation errors 350 that were encountered.
- a parsed document 340 e.g., a stream of tokens and/or a document object model or “DOM” tree.
- the revised validation process 400 preferably comprises supplying an XML source file 410 (which may be equivalent to XML source file 310 of FIG. 3) and an XML schema 420 to parser 440 .
- the XML schema 420 may have been revised since the XML source file 410 was created, and thus the source file might have become out of alignment with the schema to which it should adhere.
- the schema 420 includes an identification of a “schema change document” 430 that has been created, according to preferred embodiments, to record changes that have been made to the schema.
- This schema change document provides a single point of access by parser 440 for implementing the programmatic revisions for a single XML file or for an entire set of XML files (referred to equivalently herein as “XML documents”) that may have become out of alignment with its schema.
- XML documents referred to equivalently herein as “XML documents”.
- outputs of the validation process 400 may include a parsed document 450 and/or a report of the validation errors 460 that were encountered.
- the report of validation errors preferably includes the out-of-alignment situations that are programmatically repaired by the present invention.
- the report might include only the non-repairable errors (in which case the errors are likely due to causes other than schema changes, such as programmer error when writing the code that generated the XML file 410 being validated).
- the programmatic revisions are made only to an in-memory copy (e.g., the DOM tree) of a document being validated.
- the revisions can be used to rewrite the source document.
- a separate copy of the source document, including the programmatic revisions can be created in yet another aspect, thereby leaving the source document itself intact while persisting the revisions.
- FIG. 4 shows that another (optional) output of the validation process 400 may be a revised XML source file 470 .
- FIGS. 5-7 provide flowcharts illustrating logic that may be used when implementing preferred embodiments of the present invention.
- the flowchart in FIG. 5 illustrates operation of preferred embodiments of validation process 400
- FIGS. 6 and 7 provide further details, as will now be described.
- FIG. 5 begins (Block 500 ) for a particular XML file to be validated, by reading the XML schema (Block 505 ) and the XML file (Block 510 ).
- Block 505 reads the schema 420
- Block 510 reads the XML source file 410 .
- the input files are sent to (i.e., read by) the parser (see element 440 of FIG. 4), which then validates the XML source file against the schema.
- the test in Block 530 indicates that, if the validation is successful, then the processing of FIG. 5 is complete and the validated file (see element 450 of FIG. 4) or, alternatively, simply a Boolean indicator of validity is returned (Block 550 ).
- Block 530 Block 535
- a test is made to see if the schema used for this validation has changed.
- the schema read by the parser identifies a schema change document that records changes to the schema.
- FIGS. 8-14 illustrate how preferred embodiments programmatically detect schema changes and attempt programmatic repairs to an input file that has failed a validation (e.g., as represented by taking the “is not valid” branch from Block 530 to Block 535 ).
- FIG. 8A provides a first sample XML document 800 , comprising a root element named “rootElement” (see 810 ) that has two child elements.
- the first child element is named “branchelement1” (see 820 ) and the second child element is named “branchElement2” (see 830 ).
- Each of these elements has two child elements, named “leafElement1” and “leafElement2”.
- all of the elements except for the root include two attributes, which (in each case) are named “propertyA” and “propertyB”.
- FIG. 8B provides a tree structure 850 that corresponds to document 800 .
- schema 1000 includes the appropriate element and type definitions. See, for example, the type definition 1020 for “rootElementType”, which specifies that both “branchElement1” and “branchElement2” are required as child elements when using this type (and in particular, for the “rootElement” node 1010 that is defined to have this type).
- the XML document 900 in FIG. 9A would be invalid if using schema 1000 of FIG. 10 for validation (because it lacks the required “branchElement2” element).
- This document 900 does, however, conform to the revised schema 1100 defined in FIG. 11, because in document 900 , the “rootElement” element has only a “branchElement1” child (see 910 ).
- the tree 950 in FIG. 9B represents the document 900 shown in FIG. 9A.
- the “revised” schema 1100 shown in FIG. 11 includes a definition 1110 for a “changeDoc” element.
- This is an element used by preferred embodiments to embed a reference to the schema change document into a schema that has been revised.
- This schema change document is a document separate from the schema itself, and as stated earlier, is used to describe the changes made to the schema. According to preferred embodiments, this document contains information about one or more of the following types of changes:
- the schema change document records elements whose definition changed. For example, if an optional value was changed to a required value, that would be reflected here.
- an element might be promoted within the schema, such that elements which had been its siblings are now its children. Or, similarly, an element might be demoted, such that it becomes a sibling of its former child elements.
- FIG. 12 illustrates the general format of a sample schema change document, created according to preferred embodiments to record how a schema has been changed.
- document 1200 (which is an XML document) includes a “changeDoc” element 1210 , which includes an attribute 1220 that specifies the location of the schema by which this schema change document itself is validated.
- changeDoc element 1210
- attribute 1220 that specifies the location of the schema by which this schema change document itself is validated.
- FIG. 14 for an example of such a schema.
- the schema 1400 in FIG. 14 (comprising FIGS. 14A and 14B) allows for recording each of the four types of changes described above. See element 1410 , which specifies that each of these is optional in a valid schema change document.
- a sample schema change document 1300 is provided, where this sample document records how the schema in FIG. 10 was changed to create the schema in FIG. 11.
- this schema change document 1300 indicates (see 1310 ) that an element was deleted from the previous schema. This deletion has been described above with reference to the documents 800 and 900 of FIGS. 8A and 9A, where the “branchElement2” element was deleted as a child of the “rootElement” element.
- the attributes which are provided relative to this deletion are a “changed” attribute 1320 and a “location” attribute 1330 .
- the “changed” attribute records the date of the change (e.g., as a form of audit trail).
- the “location” attribute specifies where, relative to the XML document structure defined in the previous schema, the deletion was made.
- the attributes indicate that the deletion was made on Mar. 4, 2003, and impacted a child of “rootElement” that was named “branchElement2”.
- FIGS. 12-14 Many alternative syntax forms may be adopted for expressing the schema revisions, and thus the examples depicted in FIGS. 12-14 are for purposes of illustration but not of limitation.
- a syntax such as the existing XPointer (or XLink or XPath) notation may be advantageous for specifying values of the “location” attribute (and thereby identifying the location of the schema change).
- XPointer, XLink, and XPath are well known in the art, and published descriptions thereof are readily available; therefore, a detailed description thereof is not provided herein.
- the particular syntax used for describing schema changes may vary from one implementation to another without deviating from the scope of the present invention.
- the syntax that is adopted may use a combination of location/action pairs, whereby a pointer to a specific location in the schema is combined with a custom action tag to add/remove/move/change an element at that location.
- the “changed” and “location” attributes are preferably used in an analogous manner to that which has been described with reference to the “deletedElements” element 1310 in FIG. 13. See element 1420 of FIG. 14.
- a “definition” attribute is preferably used for specifying the syntax of the added element. Values of this attribute are preferably specified as strings, as shown at 1421 , and these strings preferably contain markup language syntax for the added element.
- default values may be specified within the schema change document for the elements that are being added.
- an implementation of the present invention may be adapted for supplying values in another manner.
- the implementation might be coded to supply empty/null values, or to prompt a user for default values, and so forth.
- the migration can be carried out by inserting the new syntax, intact, into the file being migrated. This approach may also be used to provide default values for attributes/properties.
- Element 1430 specifies allowable syntax for recording deleted elements, which have been described above.
- element 1440 indicates that preferred embodiments include attributes for the date of the change (i.e., the “changed” attribute), and for the “source” and “destination” of the move.
- the values of the “source” and “destination” attributes are defined in a similar manner as the value of “location” attribute 1330 .
- moving an element within a schema may be considered analogous to first deleting the element from its original location, and then adding the element at its new location.
- alternative embodiments may omit support for moving elements without deviating from the scope of the present invention. (Note, however, that providing support for moving elements enables flexibly transferring the contents of the element.)
- Element 1450 defines attributes that are preferably used for modified elements. Again, the “location” and “changed” attributes are preferably used to record the location and date of the modification.
- a “modification” element 1451 may be used to provide a description of a particular modification. Preferably, modifications are described in terms of added, deleted, moved, or modified properties/attributes. As noted above, these types of changes to properties/attributes may be specified within the tags for element changes, and in this case such changes may be specified within the ⁇ modifiedElement> definition of a schema change document (with a corresponding change to the syntax at 1450 ).
- Block 535 tests to see if any schema changes have been recorded that might be used for this purpose.
- the input schema is checked to see if it contains a “changeDoc” element, and if so, then Block 535 has a positive result and control passes to Block 540 .
- this “changeDoc” element is found at 1110 .
- the test in Block 535 has a negative result. This negative result indicates that the present invention is not able to repair the input document, and thus control transfers to Block 555 where an indicator of the invalidity (such as error report 460 of FIG. 4) is returned.
- Block 540 the repair (i.e., programmatic migration) process continues by reading the schema change document identified on the “changeDoc” element of the input schema.
- the document is identified as “ChangeDoc.xml”. Thus, this document is located and read. For purposes of illustration, assume that this identifies document 1300 of FIG. 13.
- Block 545 then tests to see if the changes recorded in the schema change document are applicable to the validation problem that has been identified in the current XML input file.
- the schema change document might record one or more changes, and thus this test represents an iterative process.
- FIG. 6 provides an illustration of logic that may be used for implementing the test in Block 545 .
- this logic begins (Block 600 )
- the changes recorded in the schema change document are first sorted into chronological order at Block 605 (which allows for changes that reference other changes to be properly interpreted).
- Block 610 checks to see if all the changes have been read. If so, then a change that applies to the current validation problem was not located, and the processing of FIG. 6 will therefore exit by returning a “not applicable” indication at Block 615 .
- Block 620 which reads the next change from the sorted changes.
- Block 640 checks to see if (1) this is an added element change and (2) the current validation problem is that this added element is not present in the XML file being processed by FIG. 5. If this test has a positive result, then an “applicable” indication is returned at Block 645 , and the processing of FIG. 6 exits.
- Block 635 checks to see if (1) this is a deleted element change and (2) the current validation problem is that this element is still present in the XML file being processed by FIG. 5. If this test has a positive result, then an “applicable” indication is returned at Block 645 , and the processing of FIG. 6 exits.
- Block 630 checks to see if (1) this is a moved element change and (2) the current validation problem is that this element is not present in the correct place in the XML file being processed by FIG. 5. If this test has a positive result then an “applicable” indication is returned at Block 645 , and the processing of FIG. 6 exits.
- Block 625 checks to see if (1) this is a modify element change and (2) the current validation problem is that this element has improper syntax in the XML file being processed by FIG. 5. If this test has a positive result, then an “applicable” indication is returned at Block 645 , and the processing of FIG. 6 exits.
- FIG. 7 illustrates logic that may be used for implementing the processing of Block 525 . Processing efficiencies may be realized by incorporating the logic of FIG. 6, which determines whether any schema changes are applicable to the current validation problem, with the actual application of the change. Thus, Blocks 700 - 740 are identical to Blocks 600 - 640 , with the exception that Block 715 simply finishes or returns control to the invoking logic.
- the additional functionality represented in FIG. 7 comprises Block 745 - 760 .
- the applicable change that has been located in the schema change document is applied to modify, move, delete, or add an element, respectively, in the XML file being validated.
- Block 520 optionally writes the revised file in place of the original file. Or, as discussed earlier, it may be desirable in some aspects to apply the changes only to the in-memory version (and to therefore omit Block 520 ), which enables efficiently rejecting changes if the file cannot be completely repaired. In other aspects, it may be desirable to make a copy of the input file, and write the changes to this copy at Block 520 . In another approach, changes to the original file (or to the copy) may be delayed until determining that the file can be completely repaired.
- a “repaired” flag might be set following Block 525 , and the function of Block 520 might then be moved to the “is valid” branch from Block 530 where it would be preceded by a test of the “repaired” flag and skipped if this flag is false.)
- Block 515 sends the programmatically migrated XML file back through the parsing process.
- Block 530 will then validate this revised XML file against the input schema to determine whether there are any more elements that do not adhere to the schema. This validation process occurs as described above for the original input document, until either (1) performing enough repairs on the file that it will pass the validation or (2) determining that the file cannot be repaired in view of the recorded schema changes.
- repairs may be attempted in a proactive manner, such as checking for schema changes and applying any applicable changes before beginning the validation of a particular XML file or files.
- enhancements may be provided in a particular implementation of the present invention.
- these enhancements include (but are not limited to) one or more of the following: (1) prompting the user to accept or reject changes; (2) prompting the user for additional data needed (e.g, instead of using default data); (3) alerting the user that changes are being made; (4) showing the user all changes that are necessary, and then exiting without actually making the changes; and (5) prompting the user to indicate whether changes should be written to the source XML file (and/or a copy thereof), or should only be applied to the in-memory copy.
- the present invention defines advantageous techniques for programmatically migrating an XML file such that it adheres to a current version of an XML schema.
- This migration may be done temporarily to each XML file at run-time, either as validation errors are discovered or as a precursor to attempting validation (as was discussed earlier).
- the migration may be applied in a batch mode, whereby a number of XML files are preprocessed to determine whether they are valid.
- the repairs are preferably made permanent by overwriting the original (invalid) file.
- the repairs may be permanent, or they may be temporary (e.g., in the form of modifications to an in-memory copy of the input file).
- Advantages of the present invention include recording all schema changes in a single location (i.e., the schema change document, in preferred embodiments) while keeping the change history separate from, yet linked to, the schema itself.
- the disclosed techniques provide a migration/repair approach that operates in a “run-time progressive” mode (which may interactively involve a user, if desired). This is in contrast to prior art techniques, which are either run-time “regressive” (i.e., they try to validate the XML input file against an older version of the schema if the initial validation fails), or “batch progressive” (i.e., they require batch-mode revision of XML files, rather than providing dynamic, run-time migration).
- the temporary or transient, in-memory (e.g., DOM tree) modification approach disclosed herein is also advantageous in many situations, such as when a schema is volatile during software development.
- the disclosed techniques may be considered a “rule-based” repair approach, in that the changes specified in a schema change document may be considered rules that define the programmatic repairs that are allowable for a particular schema. This rule-based detection and migration approach is preferred over prior art techniques that are dependent on schema version numbers.
- the disclosed techniques may also be used advantageously in methods of doing business, for example by providing dynamic data migration services for clients.
- This service may be provided under various revenue models, such as pay-per-use billing, monthly or other periodic billing, and so forth.
- the class library is then preferably programmatically re-generated such that it includes code for the multiple schema versions. This allows run-time functioning of code prepared according to any of the schema versions.
- the techniques disclosed therein are not directed toward enabling XML files that have become out of alignment with their schema to be programmatically migrated.
- embodiments of the present invention may be provided as methods, systems, or computer program products. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product which is embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and so forth) having computer-usable program code embodied therein.
- computer-usable storage media including, but not limited to, disk storage, CD-ROM, optical storage, and so forth
- These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart and/or block diagram block or blocks.
- the computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart and/or block diagram block or blocks.
Abstract
Techniques are disclosed for programmatically migrating structured documents created according to one version of a schema such that those structured documents may adhere to a revised version of the schema (or schema equivalent, alternatively). A “schema change document” is used to record changes that have been made to the schema. This schema change document provides a single point of access for implementing programmatic revisions for a single source file or for an entire set of source files that may have become out of alignment with its schema. The source file(s), or a copy thereof, can then be changed programmatically in view of the recorded schema changes, without having to manually search for and change all of the source files that are dependent on a changed schema
Description
- 1. Field of the Invention
- The present invention relates to computer software, and deals more particularly with techniques for programmatically migrating structured documents created according to one version of a schema such that those structured documents may adhere to a revised version of the schema (or schema equivalent, alternatively).
- 2. Description of the Related Art
- The popularity of distributed computing networks and network computing has increased tremendously in recent years, due in large part to growing business and consumer use of the public Internet and the subset thereof known as the “World Wide Web” (or simply “Web”). Other types of distributed computing networks, such as corporate intranets and extranets, are also increasingly popular. As solutions providers focus on delivering improved Web-based computing, many of the solutions which are developed are adaptable to other distributed computing environments. Thus, references herein to the Internet and Web are for purposes of illustration and not of limitation.
- Use of structured documents encoded in a structured markup language has become increasingly prevalent in recent years as a means for exchanging information between computers in distributed computing networks. In addition, many of today's software products are written to produce and consume information which is represented using these types of structured documents. The Extensible Markup Language, or “XML”, for example, is a markup language which has proven to be extremely popular for encoding structured documents for exchange between parties (and also for describing structured data). XML is very well suited for encoding document content covering a broad spectrum. XML has also been used as a foundation for many other derivative markup languages, such as the Wireless Markup Language (“WML”), VoiceXML, MathML, and so forth. These markup languages are well known in the art.
- For the early uses of structured documents, and in particular for XML version 1.0, a Document Type Definition (“DTD”) was used for specifying the grammar for a particular structured document (or set of documents). That is, a DTD specifies the set of allowable markup tags, where this set indicates the permissible elements and attributes to be used in the document(s). In more recent years, a “schema” is commonly used instead of a DTD. A schema contains information similar to that in a DTD, but is much more functionally rich, and attempts to specify more requirements for the structured documents which adhere to it. As stated by the World Wide Web Consortium (“W3C”), “XML Schemas express shared vocabularies and allow machines to carry out rules made by people. They provide a means for defining the structure, content and semantics of XML documents.”. Documents discussing schemas may be found in many places, including the W3C Web site. Today, schemas are well known in the art.
- There may be situations where a schema is undergoing revision, as the content and/or format of the structured documents that will adhere to the schema is redesigned. During development of a software product, for example, non-finalized XML schemas may be changed frequently, often in very minor ways. Addition of a new software feature might require that an additional property be added to the schema, or that a schema property be moved to a different logical location. Revising the schema has the effect of invalidating all existing XML files that are currently validated against that schema. In the case of a major software development project, this could mean the need for sweeping hundreds of files, making the same minor change (or changes) in each one. As will be obvious, revising the XML files to adhere to the new schema is a time-consuming task. Even more troubling for the software developer, though, may be the workflow interruption caused when the validation process for a file “breaks” due to the file becoming out of alignment with the changed schema. And when the schema is still fluctuating, it may happen that changes made one day are reversed the next day, exacerbating the problem for the software developers.
- It is desirable to provide techniques for addressing these problems of the prior art.
- An object of the present invention is to provide techniques for programmatically migrating structured documents created according to one version of a schema such that those structured documents may adhere to a revised version of the schema.
- Another object of the present invention is to provide techniques for dynamically migrating data encoded in a structured markup language such that the data aligns with a revised data definition.
- A further object of the present invention is to provide techniques for programmatically attempting to repair structured document content that fails a validation process.
- Other objects and advantages of the present invention will be set forth in part in the description and in the drawings which follow and, in part, will be obvious from the description or may be learned by practice of the invention.
- To achieve the foregoing objects, and in accordance with the purpose of the invention as broadly described herein, the present invention provides methods, systems, and computer program products for programmatically migrating data. In preferred embodiments, this technique comprises: recording one or more changes that are made to a first structured language specification when creating a second structured language specification; and using the recorded changes to programmatically migrate contents of a source file encoded to adhere to the first structured language specification such that it adheres to the second structured language specification. Preferably, the changes are recorded in a single location, and in particular, this single location is preferably a change file that is identified in, but physically separate from, the second structured language specification.
- The first structured language specification and the second structured language specification are preferably schemas (or schema equivalents).
- Optionally, the recorded changes may represent one or more interim versions of the structured language specification. In this case, a subset of the changes will be the result of creating the interim version(s), and the remaining changes will reflect changing the final interim version to become the second structured language specification. Thus, the source file that is programmatically migrated may have been originally encoded to adhere to any of the interim structured language specifications (rather than the first structured language specification).
- The programmatic migration may be responsive to detecting a validation error when attempting to validate the contents of the source file (e.g., using a parser) against the second structured language specification, or it may be triggered in another way, including as a precursor to attempting such a validation. The programmatic migration may comprise revising the contents of the source file, an in-memory representation of the contents of the source file, and/or a copy of the contents of the source file. Optionally, a user may be prompted before changing the contents of one or more of these files.
- The source file is preferably encoded in a structured markup language such as XML (or a derivative thereof), and the first and second structured language specifications then define allowable syntax for files encoded in this structured markup language.
- The present invention may also be used advantageously in methods of doing business, for example by providing dynamic data migration services for clients. This service may be provided under various revenue models, such as pay-per-use billing, monthly or other periodic billing, and so forth.
- The present invention will now be described with reference to the following drawings, in which like reference numbers denote the same element throughout.
- FIG. 1 is a block diagram of a computer hardware environment in which the present invention may be practiced, according to the prior art;
- FIG. 2 is a diagram of a networked computing environment in which the present invention may be practiced, according to the prior art;
- FIGS. 3 and 4 illustrate components involved when validating structured documents according to the prior art and according to preferred embodiments of the present invention, respectively;
- FIGS. 5-7 provide flowcharts illustrating logic that may be used when implementing preferred embodiments of the present invention;
- FIGS. 8 and 9 (comprising FIGS. 8A and 8B,9A and 9B) provide sample XML documents and their corresponding tree structures, and are used to illustrate operation of preferred embodiments;
- FIG. 10 depicts a first version of a sample schema that may be used when validating the XML documents in FIGS. 8A and 9A, and FIG. 11 depicts a modified version of this sample schema that may be used for validating the same documents;
- FIG. 12 illustrates the general format of a sample schema change document, created according to preferred embodiments to record how a schema has been changed, and FIG. 13 provides a schema change document that records how the schema in FIG. 10 was changed to create the schema in FIG. 11; and
- FIG. 14 illustrates a schema defining the allowable contents (i.e., grammar) of a schema change document, according to preferred embodiments.
- The present invention provides techniques for programmatically migrating structured documents created according to one version of a schema, such that those structured documents may adhere to a revised version of the schema. For purposes of illustration but not of limitation, preferred embodiments of the present invention are described in terms of elements of XML documents defined according to an XML schema. However, the inventive concepts disclosed herein may be adapted to elements encoded in other structured markup languages and/or which are defined using other definitional approaches (such as document type definitions, or “DTDs”). Thus, references herein to “XML” and “schema” are intended to encompass functionally similar languages and definitions.
- The present invention allows changes to be made to XML schemas without having to manually change all dependent XML files (and without having to search for the files that are dependent). In a typical software development environment, many schema changes may be made that are of minor to moderate complexity, and such changes may be made rapidly and frequently throughout the development process. Using techniques disclosed herein, the dependent XML files can by revised programmatically, using knowledge of the particular schema changes that have been made. (This knowledge also enables determining whether any validation problems that arise are simply due to the schema changes, or instead signify an error in the document-producing logic.)
- Preferred embodiments of the present invention will now be described with reference to FIGS. 1-14.
- FIG. 1 illustrates a representative computer hardware environment in which the present invention may be practiced. The environment of FIG. 1 comprises a
representative computer workstation 10, such as a personal computer, including related peripheral devices. Theworkstation 10 includes amicroprocessor 12 and abus 14 employed to connect and enable communication between themicroprocessor 12 and the components of theworkstation 10 in accordance with known techniques. Theworkstation 10 typically includes auser interface adapter 16, which connects themicroprocessor 12 via thebus 14 to one or more interface devices, such as akeyboard 18,mouse 20, and/orother interface devices 22, which can be any user interface device, such as a touch sensitive screen, digitized entry pad, etc. Thebus 14 also connects adisplay device 24, such as an LCD screen or monitor, to themicroprocessor 12 via adisplay adapter 26. Thebus 14 also connects themicroprocessor 12 tomemory 28 and long-term storage 30 which can include a hard drive, diskette drive, tape drive, etc. - The
workstation 10 may communicate with other computers or networks of computers, for example via a communications channel ormodem 32. Alternatively, theworkstation 10 may communicate using a wireless interface at 32, such as a cellular digital packet data (“CDPD”) card. Theworkstation 10 may be associated with such other computers in a local area network (“LAN”) or a wide area network (“WAN”), or theworkstation 10 can be a client in a client/server arrangement with another computer, etc. All of these configurations, as well as the appropriate communications hardware and software, are known in the art. - FIG. 2 illustrates a
data processing network 40 in which the present invention may be practiced. Thedata processing network 40 may include a plurality of individual networks, such aswireless network 42 andnetwork 44, each of which may include a plurality ofindividual workstations 10. Additionally, as those skilled in the art will appreciate, one or more LANs may be included (not shown), where a LAN may comprise a plurality of intelligent workstations coupled to a host processor. - Still referring to FIG. 2, the
networks gateway computer 46 or application server 47 (which may access a data repository 48). Agateway computer 46 serves as a point of entry into eachnetwork 44. Thegateway 46 may be coupled to anothernetwork 42 by means of a communications link 50 a. Thegateway 46 may also be directly (or indirectly) coupled to one ormore workstations 10 using acommunications link gateway computer 46 may also be coupled 49 to a storage device (such as data repository 48). Thegateway computer 46 may be implemented utilizing an Enterprise Systems Architecture/370™ available from the International Business Machines Corporation (“IBM®”), an Enterprise Systems Architecture/390® computer, etc. Depending on the application, a midrange computer, such as an Application System/400® (also known as an AS/400®) may be employed. (“Enterprise Systems Architecture/370” is a trademark of IBM; “IBM”, “Enterprise Systems Architecture/390”, “Application System/400”, and “AS/400”are registered trademarks of IBM.) - Those skilled in the art will appreciate that the
gateway computer 46 may be located a great geographic distance from thenetwork 42, and similarly, theworkstations 10 may be located a substantial distance from thenetworks network 42 may be located in California, while thegateway 46 may be located in Texas, and one or more of theworkstations 10 may be located in Florida. Theworkstations 10 may connect to thewireless network 42 using a networking protocol such as the Transmission Control Protocol/Internet Protocol (“TCP/IP”) over a number of alternative connection media, such as cellular phone, radio frequency networks, satellite networks, etc. Thewireless network 42 preferably connects to thegateway 46 using anetwork connection 50 a such as TCP or User Datagram Protocol (“UDP”) over IP, X.25, Frame Relay, Integrated Services Digital Network (“ISDN”), Public Switched Telephone Network (“PSTN”), etc. Theworkstations 10 may alternatively connect directly to thegateway 46 usingdial connections wireless network 42 andnetwork 44 may connect to one or more other networks (not shown), in an analogous manner to that depicted in FIG. 2. - In preferred embodiments, the present invention is provided in software. In this case, software programming code which embodies the present invention is typically accessed by the
microprocessor 12 of theworkstation 10 orserver 47 from long-term storage media 30 of some type, such as a CD-ROM drive or hard drive. The software programming code may be embodied on any of a variety of known media for use with a data processing system, such as a diskette, hard drive, or CD-ROM. The code may be distributed on such media, or may be distributed from the memory or storage of one computer system over a network of some type to other computer systems for use by such other systems (and their users). Alternatively, the programming code may be embodied in thememory 28, and accessed by themicroprocessor 12 using thebus 14. The techniques and methods for embodying software programming code in memory, on physical media, and/or distributing software code via networks are well known and will not be further discussed herein. - The computing environment in which the present invention may be used includes an Internet environment, an intranet environment, an extranet environment, or any other type of networking environment. These environments may be structured in various ways, including a client-server architecture or a multi-tiered architecture. The present invention may also be used in a disconnected (i.e., stand-alone) mode, for example where a user validates an XML file on a workstation, server, or other computing device without communicating across a computing network.
- FIG. 3 illustrates components involved when validating structured documents according to the prior art. As shown therein, the
validation process 300 comprises supplying an XML source file 310 and anXML schema 320 to acomponent 330 that is referred to herein as a parser. (While preferred alternatives are described with reference to a parser, an alternative validating component —such as a specially-designed validator—may be used, and such alternatives are within the scope of the present invention.)Parser 330 usesschema 320 to determine, inter alia, whether XML source file 310 is a valid document. Therefore, the terms “parse” and “validate” are used synonymously herein for purposes of describing the present invention. If the source file 310 is valid, then an output of the parsing process is a parsed document 340 (e.g., a stream of tokens and/or a document object model or “DOM” tree). If the source file 310 is not valid, then an output of the parsing process is typically a report of thevalidation errors 350 that were encountered. - In FIG. 4, components involved when validating structured documents according to preferred embodiments are depicted. The revised
validation process 400 preferably comprises supplying an XML source file 410 (which may be equivalent to XML source file 310 of FIG. 3) and anXML schema 420 toparser 440. TheXML schema 420 may have been revised since the XML source file 410 was created, and thus the source file might have become out of alignment with the schema to which it should adhere. - According to preferred embodiments, the
schema 420 includes an identification of a “schema change document” 430 that has been created, according to preferred embodiments, to record changes that have been made to the schema. This schema change document provides a single point of access byparser 440 for implementing the programmatic revisions for a single XML file or for an entire set of XML files (referred to equivalently herein as “XML documents”) that may have become out of alignment with its schema. The manner in which the schema change document is identified, and how it is used to programmatically revise one or more XML files, will be described in detail below. (See, for example, the discussion of FIGS. 10-14.) - As described with reference to FIG. 3, outputs of the
validation process 400 may include a parseddocument 450 and/or a report of thevalidation errors 460 that were encountered. The report of validation errors preferably includes the out-of-alignment situations that are programmatically repaired by the present invention. Alternatively, the report might include only the non-repairable errors (in which case the errors are likely due to causes other than schema changes, such as programmer error when writing the code that generated theXML file 410 being validated). - In one aspect, the programmatic revisions are made only to an in-memory copy (e.g., the DOM tree) of a document being validated. In another aspect, the revisions can be used to rewrite the source document. Or, a separate copy of the source document, including the programmatic revisions, can be created in yet another aspect, thereby leaving the source document itself intact while persisting the revisions. Thus, FIG. 4 shows that another (optional) output of the
validation process 400 may be a revisedXML source file 470. - FIGS. 5-7 provide flowcharts illustrating logic that may be used when implementing preferred embodiments of the present invention. The flowchart in FIG. 5 illustrates operation of preferred embodiments of
validation process 400, and FIGS. 6 and 7 provide further details, as will now be described. - The processing of FIG. 5 begins (Block500) for a particular XML file to be validated, by reading the XML schema (Block 505) and the XML file (Block 510). (With reference to FIG. 4,
Block 505 reads theschema 420 andBlock 510 reads theXML source file 410.) AtBlock 515, the input files are sent to (i.e., read by) the parser (seeelement 440 of FIG. 4), which then validates the XML source file against the schema. The test inBlock 530 indicates that, if the validation is successful, then the processing of FIG. 5 is complete and the validated file (seeelement 450 of FIG. 4) or, alternatively, simply a Boolean indicator of validity is returned (Block 550). - However, if the validation is not successful, then control transfers from
Block 530 to Block 535, where a test is made to see if the schema used for this validation has changed. As stated earlier, in preferred embodiments, the schema read by the parser identifies a schema change document that records changes to the schema. Reference will now be made to the example documents in FIGS. 8-14 to illustrate how preferred embodiments programmatically detect schema changes and attempt programmatic repairs to an input file that has failed a validation (e.g., as represented by taking the “is not valid” branch fromBlock 530 to Block 535). - FIG. 8A provides a first
sample XML document 800, comprising a root element named “rootElement” (see 810) that has two child elements. The first child element is named “branchelement1” (see 820) and the second child element is named “branchElement2” (see 830). Each of these elements has two child elements, named “leafElement1” and “leafElement2”. For thisexample document 800, all of the elements except for the root include two attributes, which (in each case) are named “propertyA” and “propertyB”. FIG. 8B provides atree structure 850 that corresponds to document 800. - Suppose for purposes of discussion that document800 was valid when it was created. An example of a schema that supports this
document definition 800 is provided in FIG. 10, whereschema 1000 includes the appropriate element and type definitions. See, for example, thetype definition 1020 for “rootElementType”, which specifies that both “branchElement1” and “branchElement2” are required as child elements when using this type (and in particular, for the “rootElement”node 1010 that is defined to have this type). - Further suppose that the software developers then decide to remove “branchElement2” as a child of “rootElement”. A revised
schema 1100 is provided in FIG. 11, and in this revised schema, the “rootElementType” for the element “rootElement” (see 1120) has a single child element, namely the “branchElement1” child (see 1130). Thus, when usingschema 1100, theXML document 800 in FIG. 8A is invalid because the “branchElement2”element at 830 is not permitted. - The
XML document 900 in FIG. 9A, on the other hand, would be invalid if usingschema 1000 of FIG. 10 for validation (because it lacks the required “branchElement2” element). Thisdocument 900 does, however, conform to the revisedschema 1100 defined in FIG. 11, because indocument 900, the “rootElement” element has only a “branchElement1” child (see 910). Thetree 950 in FIG. 9B represents thedocument 900 shown in FIG. 9A. - Note that the “revised”
schema 1100 shown in FIG. 11 includes adefinition 1110 for a “changeDoc” element. This is an element used by preferred embodiments to embed a reference to the schema change document into a schema that has been revised. This schema change document is a document separate from the schema itself, and as stated earlier, is used to describe the changes made to the schema. According to preferred embodiments, this document contains information about one or more of the following types of changes: - 1) Elements that have been added. The schema change document notes any elements that had been added. Optionally, an embodiment of the present invention may support specifying a default value to use during the programmatic migration process in cases where the XML file being validated did not contain this added element.
- 2) Elements that have been removed.
- 3) Elements that have been moved. The schema change document describes elements whose data was moved to another location in the schema. (Such changes may be represented in a similar manner to combining an “Element removed” and an “Element added” change, with the added benefit of the element's data being transferred to the new location.)
- 4) Elements that have been changed. The schema change document records elements whose definition changed. For example, if an optional value was changed to a required value, that would be reflected here.
- As one example of a schema change that may be described in the schema change document, an element might be promoted within the schema, such that elements which had been its siblings are now its children. Or, similarly, an element might be demoted, such that it becomes a sibling of its former child elements.
- Additional and/or different types of changes may be specified in the schema change document, without deviating from the scope of the present invention. (As an example, identification of elements that have been renamed might be provided as another choice within the schema change document.) Furthermore, changes to properties/attributes may be specified within the tags for element changes (see the discussion of
reference number 1450 of FIG. 14, for example), or separate tags may be provided for such changes. - FIG. 12 (comprising FIGS. 12A and 12B) illustrates the general format of a sample schema change document, created according to preferred embodiments to record how a schema has been changed. As shown therein, document1200 (which is an XML document) includes a “changeDoc”
element 1210, which includes anattribute 1220 that specifies the location of the schema by which this schema change document itself is validated. Refer to FIG. 14 for an example of such a schema. Notably, theschema 1400 in FIG. 14 (comprising FIGS. 14A and 14B) allows for recording each of the four types of changes described above. Seeelement 1410, which specifies that each of these is optional in a valid schema change document. - In FIG. 13, a sample
schema change document 1300 is provided, where this sample document records how the schema in FIG. 10 was changed to create the schema in FIG. 11. In particular, thisschema change document 1300 indicates (see 1310) that an element was deleted from the previous schema. This deletion has been described above with reference to thedocuments schema change document 1300, the attributes which are provided relative to this deletion are a “changed”attribute 1320 and a “location”attribute 1330. The “changed” attribute records the date of the change (e.g., as a form of audit trail). The “location” attribute specifies where, relative to the XML document structure defined in the previous schema, the deletion was made. In this example, the attributes indicate that the deletion was made on Mar. 4, 2003, and impacted a child of “rootElement” that was named “branchElement2”. - Many alternative syntax forms may be adopted for expressing the schema revisions, and thus the examples depicted in FIGS. 12-14 are for purposes of illustration but not of limitation. A syntax such as the existing XPointer (or XLink or XPath) notation may be advantageous for specifying values of the “location” attribute (and thereby identifying the location of the schema change). XPointer, XLink, and XPath are well known in the art, and published descriptions thereof are readily available; therefore, a detailed description thereof is not provided herein. The particular syntax used for describing schema changes may vary from one implementation to another without deviating from the scope of the present invention. The syntax that is adopted may use a combination of location/action pairs, whereby a pointer to a specific location in the schema is combined with a custom action tag to add/remove/move/change an element at that location.
- Reference will now be made to the
schema change definition 1400 of FIG. 14 (as illustrated by thesample document 1200 in FIG. 12) for a discussion of attributes that may be used when adding, removing, moving, and changing elements in a schema. - When an element is added to a schema, the “changed” and “location” attributes are preferably used in an analogous manner to that which has been described with reference to the “deletedElements”
element 1310 in FIG. 13. Seeelement 1420 of FIG. 14. In addition, a “definition” attribute (see 1421) is preferably used for specifying the syntax of the added element. Values of this attribute are preferably specified as strings, as shown at 1421, and these strings preferably contain markup language syntax for the added element. - Optionally, default values may be specified within the schema change document for the elements that are being added. (Alternatively, an implementation of the present invention may be adapted for supplying values in another manner. For example, the implementation might be coded to supply empty/null values, or to prompt a user for default values, and so forth.)
- As one way in which default values may be specified within the schema change document, the <addedElement>
element 1230 in FIG. 12 might be replaced by the following syntax (with a corresponding modification to theschema 1400 in FIG. 14):<addedElement changed=“2003-03-04” location= “String describing the location of the new added element, like ‘rootElement’” definition=“The definition of the newly added element”> <defaultData> . . . Optional default data . . . </defaultData> </addedElement> - As another example, the following approach might be used, where a multi-line string is specified that contains new markup language syntax (where the syntax in this example supplies the specification for “branchElement2” and its child elements, as those elements are shown at
reference number 830 of FIG. 8A):<addedElement changed=“2003-03-04” location= “String describing the location of the new added element, like ‘rootElement’” definition= “<![CDATA[ <branchElement2 propertyA=“myProperty” propertyB=“anotherProperty”> <leafElement1 propertyA=“yetAnotherProperty” propertyB=“blahblahblah”/> <leafElement2 propertyA=“yetAnotherProperty” propertyB=“blahblahblah”/> </branchElement2> ]]>” - The migration can be carried out by inserting the new syntax, intact, into the file being migrated. This approach may also be used to provide default values for attributes/properties.
-
Element 1430 specifies allowable syntax for recording deleted elements, which have been described above. - For elements that have been moved when creating a revised schema,
element 1440 indicates that preferred embodiments include attributes for the date of the change (i.e., the “changed” attribute), and for the “source” and “destination” of the move. Preferably, the values of the “source” and “destination” attributes are defined in a similar manner as the value of “location”attribute 1330. As noted above, moving an element within a schema may be considered analogous to first deleting the element from its original location, and then adding the element at its new location. Thus, alternative embodiments may omit support for moving elements without deviating from the scope of the present invention. (Note, however, that providing support for moving elements enables flexibly transferring the contents of the element.) -
Element 1450 defines attributes that are preferably used for modified elements. Again, the “location” and “changed” attributes are preferably used to record the location and date of the modification. In addition, a “modification”element 1451 may be used to provide a description of a particular modification. Preferably, modifications are described in terms of added, deleted, moved, or modified properties/attributes. As noted above, these types of changes to properties/attributes may be specified within the tags for element changes, and in this case such changes may be specified within the <modifiedElement> definition of a schema change document (with a corresponding change to the syntax at 1450). - The discussion now returns to the validation process of FIG. 5, where (for purposes of illustration) the
document 800 of FIG. 8A is being validated against the revisedschema 1100 of FIG. 11. According toelement 1130 of the schema,element 830 of the input document is invalid. Rather than simply returning an error (and halting further processing of the input file), as in the prior art, control reachesBlock 535, where an attempt to repair the input document according to the present invention begins.Block 535 tests to see if any schema changes have been recorded that might be used for this purpose. In preferred embodiments, the input schema is checked to see if it contains a “changeDoc” element, and if so, thenBlock 535 has a positive result and control passes to Block 540. Referring to thesample input schema 1100 of FIG. 11, this “changeDoc” element is found at 1110. On the other hand, if there is no “changeDoc” element (for example, in theoriginal schema 1000 of FIG. 10, which had not yet been revised), then the test inBlock 535 has a negative result. This negative result indicates that the present invention is not able to repair the input document, and thus control transfers to Block 555 where an indicator of the invalidity (such aserror report 460 of FIG. 4) is returned. - When control reaches
Block 540, the repair (i.e., programmatic migration) process continues by reading the schema change document identified on the “changeDoc” element of the input schema. In theexample input schema 1100, the document is identified as “ChangeDoc.xml”. Thus, this document is located and read. For purposes of illustration, assume that this identifiesdocument 1300 of FIG. 13.Block 545 then tests to see if the changes recorded in the schema change document are applicable to the validation problem that has been identified in the current XML input file. The schema change document might record one or more changes, and thus this test represents an iterative process. - FIG. 6 provides an illustration of logic that may be used for implementing the test in
Block 545. When this logic begins (Block 600), the changes recorded in the schema change document are first sorted into chronological order at Block 605 (which allows for changes that reference other changes to be properly interpreted).Block 610 checks to see if all the changes have been read. If so, then a change that applies to the current validation problem was not located, and the processing of FIG. 6 will therefore exit by returning a “not applicable” indication atBlock 615. - Otherwise, when there are still more changes to evaluate, control reaches
Block 620 which reads the next change from the sorted changes.Block 640 checks to see if (1) this is an added element change and (2) the current validation problem is that this added element is not present in the XML file being processed by FIG. 5. If this test has a positive result, then an “applicable” indication is returned atBlock 645, and the processing of FIG. 6 exits. - When the test in
Block 640 has a negative result, then Block 635 checks to see if (1) this is a deleted element change and (2) the current validation problem is that this element is still present in the XML file being processed by FIG. 5. If this test has a positive result, then an “applicable” indication is returned atBlock 645, and the processing of FIG. 6 exits. - When the test in
Block 635 has a negative result, then Block 630 checks to see if (1) this is a moved element change and (2) the current validation problem is that this element is not present in the correct place in the XML file being processed by FIG. 5. If this test has a positive result then an “applicable” indication is returned atBlock 645, and the processing of FIG. 6 exits. - When the test in
Block 630 has a negative result, then Block 625 checks to see if (1) this is a modify element change and (2) the current validation problem is that this element has improper syntax in the XML file being processed by FIG. 5. If this test has a positive result, then an “applicable” indication is returned atBlock 645, and the processing of FIG. 6 exits. - Otherwise, when the test in
Block 625 has a negative result (i.e., this change element is not applicable to the current validation problem), then control returns to Block 610 to determine whether there are any more changes to be evaluated. - Returning again to the discussion of FIG. 5, if the schema change document is not applicable to the current validation problem (that is, a “not applicable” indication was returned from
Block 615 of FIG. 6), then this XML input file cannot be programmatically migrated according to the present invention, and control transfers to Block 555 where an invalidity indicator is returned. - On the other hand, if a recorded change is applicable to the current validation problem, then processing continues at
Block 525 where the change is applied. Preferably, the change is made to the in-memory version of the XML input file. - FIG. 7 illustrates logic that may be used for implementing the processing of
Block 525. Processing efficiencies may be realized by incorporating the logic of FIG. 6, which determines whether any schema changes are applicable to the current validation problem, with the actual application of the change. Thus, Blocks 700-740 are identical to Blocks 600-640, with the exception thatBlock 715 simply finishes or returns control to the invoking logic. The additional functionality represented in FIG. 7 comprises Block 745-760. Here, the applicable change that has been located in the schema change document is applied to modify, move, delete, or add an element, respectively, in the XML file being validated. - Following application of the change at
Block 525,Block 520 optionally writes the revised file in place of the original file. Or, as discussed earlier, it may be desirable in some aspects to apply the changes only to the in-memory version (and to therefore omit Block 520), which enables efficiently rejecting changes if the file cannot be completely repaired. In other aspects, it may be desirable to make a copy of the input file, and write the changes to this copy atBlock 520. In another approach, changes to the original file (or to the copy) may be delayed until determining that the file can be completely repaired. (For example, a “repaired” flag might be set followingBlock 525, and the function ofBlock 520 might then be moved to the “is valid” branch fromBlock 530 where it would be preceded by a test of the “repaired” flag and skipped if this flag is false.) - Following
Block 520, or followingBlock 525 whenBlock 520 has been omitted,Block 515 sends the programmatically migrated XML file back through the parsing process.Block 530 will then validate this revised XML file against the input schema to determine whether there are any more elements that do not adhere to the schema. This validation process occurs as described above for the original input document, until either (1) performing enough repairs on the file that it will pass the validation or (2) determining that the file cannot be repaired in view of the recorded schema changes. - It should be noted that the approach described with reference to FIG. 5, where repairs are attempted only when a validation fails, is not intended to limit use of the present invention. Alternatively, repairs may be attempted in a proactive manner, such as checking for schema changes and applying any applicable changes before beginning the validation of a particular XML file or files.
- While the examples discussed above refer to changes to elements defined in a schema, this should be construed as applying also to changes to properties defined in the schema (e.g., where these properties define allowable attributes for XML documents).
- A number of optional enhancements may be provided in a particular implementation of the present invention. With regard to applying the changes documented in the schema change document to the XML file being validated, these enhancements include (but are not limited to) one or more of the following: (1) prompting the user to accept or reject changes; (2) prompting the user for additional data needed (e.g, instead of using default data); (3) alerting the user that changes are being made; (4) showing the user all changes that are necessary, and then exiting without actually making the changes; and (5) prompting the user to indicate whether changes should be written to the source XML file (and/or a copy thereof), or should only be applied to the in-memory copy.
- As has been demonstrated, the present invention defines advantageous techniques for programmatically migrating an XML file such that it adheres to a current version of an XML schema. This migration may be done temporarily to each XML file at run-time, either as validation errors are discovered or as a precursor to attempting validation (as was discussed earlier). Or, the migration may be applied in a batch mode, whereby a number of XML files are preprocessed to determine whether they are valid. In the latter case, the repairs are preferably made permanent by overwriting the original (invalid) file. In the former case, the repairs may be permanent, or they may be temporary (e.g., in the form of modifications to an in-memory copy of the input file).
- Advantages of the present invention include recording all schema changes in a single location (i.e., the schema change document, in preferred embodiments) while keeping the change history separate from, yet linked to, the schema itself. Furthermore, the disclosed techniques provide a migration/repair approach that operates in a “run-time progressive” mode (which may interactively involve a user, if desired). This is in contrast to prior art techniques, which are either run-time “regressive” (i.e., they try to validate the XML input file against an older version of the schema if the initial validation fails), or “batch progressive” (i.e., they require batch-mode revision of XML files, rather than providing dynamic, run-time migration). The temporary or transient, in-memory (e.g., DOM tree) modification approach disclosed herein is also advantageous in many situations, such as when a schema is volatile during software development. The disclosed techniques may be considered a “rule-based” repair approach, in that the changes specified in a schema change document may be considered rules that define the programmatic repairs that are allowable for a particular schema. This rule-based detection and migration approach is preferred over prior art techniques that are dependent on schema version numbers.
- The disclosed techniques may also be used advantageously in methods of doing business, for example by providing dynamic data migration services for clients. This service may be provided under various revenue models, such as pay-per-use billing, monthly or other periodic billing, and so forth.
- Commonly-assigned U.S. Pat. No.______ (Ser. No. 10/016,933), which is entitled “Generating Class Library to Represent Messages Described in a Structured Language Schema”, discloses techniques whereby class libraries are programmatically generated from a schema. Templates are used for generating code of the class libraries. According to techniques disclosed therein, optional migration logic can be programmatically generated to handle compatibility issues between multiple versions of an XML schema from which class libraries are generated. Multiple versions of an XML schema are read and compared, and a report of their differences is prepared. The differences are preferably used to generate code that handles both the original schema and the changed version(s) of the schema. The class library is then preferably programmatically re-generated such that it includes code for the multiple schema versions. This allows run-time functioning of code prepared according to any of the schema versions. The techniques disclosed therein are not directed toward enabling XML files that have become out of alignment with their schema to be programmatically migrated.
- As will be appreciated by one of skill in the art, embodiments of the present invention may be provided as methods, systems, or computer program products. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product which is embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and so forth) having computer-usable program code embodied therein.
- The present invention has been described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart and/or block diagram block or blocks.
- These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart and/or block diagram block or blocks.
- The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart and/or block diagram block or blocks.
- While the preferred embodiments of the present invention have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims shall be construed to include both the preferred embodiment and all such variations and modifications as fall within the spirit and scope of the invention.
Claims (30)
1. A method of programmatically migrating data, comprising steps of:
recording one or more changes that are made to a first structured language specification when creating a second structured language specification; and
using the recorded changes to programmatically migrate contents of a source file encoded to adhere to the first structured language specification such that it adheres to the second structured language specification.
2. The method according to claim 1 , wherein the changes are recorded in a single location.
3. The method according to claim 1 , wherein the changes are recorded in a change file.
4. The method according to claim 1 , wherein the recorded changes are identified in, but are physically separate from, the second structured language specification.
5. The method according to claim 1 , wherein the first structured language specification and the second structured language specification are schemas.
6. The method according to claim 1 , wherein a subset of the recorded changes create an interim structured language specification from the first structured language specification and remaining ones of the recorded changes create the second structured language specification from the interim structured language specification, and wherein the source file that is programmatically migrated by the using step is encoded to adhere to the interim structured language specification.
7. The method according to claim 1 , wherein the using step operates to programmatically migrate the contents of the source file responsive to detecting a validation error when attempting to validate the contents of the source file against the second structured language specification.
8. The method according to claim 1 , wherein the using step operates to programmatically migrate the contents of the source file prior to attempting to validate the contents of the source file against the second structured language specification.
9. The method according to claim 1 , wherein the programmatic migration further comprises revising the contents of the source file.
10. The method according to claim 1 , wherein the programmatic migration further comprises revising an in-memory representation of the contents of the source file.
11. The method according to claim 1 , wherein the programmatic migration further comprises revising a copy of the contents of the source file.
12. The method according to claim 1 , further comprising the step of prompting a user before changing the contents of the source file during the programmatic migration.
13. The method according to claim 8 , wherein the validation is performed by a parser.
14. The method according to claim 1 , wherein the source file is encoded in a structured markup language and the first and second structured language specifications define allowable syntax for files encoded in the structured markup language.
15. The method according to claim 14 , wherein the structured markup language is Extensible Markup Language (“XML”) or a derivative thereof.
16. A system for programmatically migrating data, comprising:
means for recording one or more changes that are made to a first structured language specification when creating a second structured language specification; and
means for using the recorded changes to programmatically migrate contents of a source file encoded to adhere to the first structured language specification such that it adheres to the second structured language specification.
17. The system according to claim 16 , wherein the recorded changes are identified in, but are physically separate from, the second structured language specification.
18. The system according to claim 16 , wherein the first structured language specification and the second structured language specification are schemas.
19. The system according to claim 16 , wherein the means for using operates to programmatically migrate the contents of the source file responsive to detecting a validation error when attempting to validate the contents of the source file against the second structured language specification.
20. The system according to claim 16 , wherein the means for using operates to programmatically migrate the contents of the source file prior to attempting to validate the contents of the source file against the second structured language specification.
21. The system according to claim 16 , wherein the programmatic migration further comprises revising one or more of: the contents of the source file; an in-memory representation of the contents of the source file; and a copy of the contents of the source file.
22. The system according to claim 16 , wherein the source file is encoded in a structured markup language and the first and second structured language specifications define allowable syntax for files encoded in the structured markup language.
23. A computer program product for programmatically migrating data, the computer program product embodied on one or more computer-usable media and comprising:
computer-readable program code means for recording one or more changes that are made to a first structured language specification when creating a second structured language specification; and
computer-readable program code means for using the recorded changes to programmatically migrate contents of a source file encoded to adhere to the first structured language specification such that it adheres to the second structured language specification.
24. The computer program product according to claim 23 , wherein the recorded changes are identified in, but are physically separate from, the second structured language specification.
25. The computer program product according to claim 23 , wherein the first structured language specification and the second structured language specification are schemas.
26. The computer program product according to claim 23 , wherein the computer-readable program code means for using operates to programmatically migrate the contents of the source file responsive to detecting a validation error when attempting to validate the contents of the source file against the second structured language specification.
27. The computer program product according to claim 23 , wherein the computer-readable program code means for using operates to programmatically migrate the contents of the source file prior to attempting to validate the contents of the source file against the second structured language specification.
28. The computer program product according to claim 23 , wherein the programmatic migration further comprises revising one or more of: the contents of the source file; an in-memory representation of the contents of the source file; and a copy of the contents of the source file.
29. The computer program product according to claim 23 , wherein the source file is encoded in a structured markup language and the first and second structured language specifications define allowable syntax for files encoded in the structured markup language.
30. A method of programmatically migrating data such that it aligns with a changing definition of allow syntax, comprising steps of:
recording one or more changes that are made to a first structured language specification when creating a second structured language specification, wherein syntax of one or more source files is intended to adhere to the first structured language specification;
upon determining that the syntax of the one or more source files should now adhere to the second structured language specification, using the recorded changes to programmatically migrate contents of at least one of the source files, such that the syntax does adhere to the second structured language specification; and
charging a fee for carrying out either or both of the recording and programmatically migrating steps.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/403,342 US20040194016A1 (en) | 2003-03-28 | 2003-03-28 | Dynamic data migration for structured markup language schema changes |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/403,342 US20040194016A1 (en) | 2003-03-28 | 2003-03-28 | Dynamic data migration for structured markup language schema changes |
Publications (1)
Publication Number | Publication Date |
---|---|
US20040194016A1 true US20040194016A1 (en) | 2004-09-30 |
Family
ID=32989917
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/403,342 Abandoned US20040194016A1 (en) | 2003-03-28 | 2003-03-28 | Dynamic data migration for structured markup language schema changes |
Country Status (1)
Country | Link |
---|---|
US (1) | US20040194016A1 (en) |
Cited By (55)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020059528A1 (en) * | 2000-11-15 | 2002-05-16 | Dapp Michael C. | Real time active network compartmentalization |
US20020066035A1 (en) * | 2000-11-15 | 2002-05-30 | Dapp Michael C. | Active intrusion resistant environment of layered object and compartment keys (AIRELOCK) |
US20040083387A1 (en) * | 2002-10-29 | 2004-04-29 | Dapp Michael C. | Intrusion detection accelerator |
US20040083221A1 (en) * | 2002-10-29 | 2004-04-29 | Dapp Michael C. | Hardware accelerated validating parser |
US20040172234A1 (en) * | 2003-02-28 | 2004-09-02 | Dapp Michael C. | Hardware accelerator personality compiler |
US20060155725A1 (en) * | 2004-11-30 | 2006-07-13 | Canon Kabushiki Kaisha | System and method for future-proofing devices using metaschema |
US20060230063A1 (en) * | 2005-04-08 | 2006-10-12 | International Business Machines Corporation | Method and apparatus for mapping structured query language schema to application specific business objects in an integrated application environment |
US20060230048A1 (en) * | 2005-04-08 | 2006-10-12 | International Business Machines Corporation | Method and apparatus for object discovery agent based mapping of application specific markup language schemas to application specific business objects in an integrated application environment |
US20060230066A1 (en) * | 2005-04-08 | 2006-10-12 | Yury Kosov | Using schemas to generate application specific business objects for use in an integration broker |
US20060277459A1 (en) * | 2005-06-02 | 2006-12-07 | Lemoine Eric T | System and method of accelerating document processing |
US20060294120A1 (en) * | 2005-06-27 | 2006-12-28 | Peng Li | Detecting migration differences of a customized database schema |
US20070061884A1 (en) * | 2002-10-29 | 2007-03-15 | Dapp Michael C | Intrusion detection accelerator |
US20070136353A1 (en) * | 2005-12-09 | 2007-06-14 | International Business Machines Corporation | System and method for data model and content migration in content management application |
US20070250766A1 (en) * | 2006-04-19 | 2007-10-25 | Vijay Medi | Streaming validation of XML documents |
US20080077632A1 (en) * | 2006-09-22 | 2008-03-27 | Tysowski Piotr K | Schema updating for synchronizing databases connected by wireless interface |
US20080077848A1 (en) * | 2006-09-21 | 2008-03-27 | International Business Machines Corporation | Capturing and Processing Change Information in a Web-Type Environment |
US20080082963A1 (en) * | 2006-10-02 | 2008-04-03 | International Business Machines Corporation | Voicexml language extension for natively supporting voice enrolled grammars |
US20080092037A1 (en) * | 2006-10-16 | 2008-04-17 | Oracle International Corporation | Validation of XML content in a streaming fashion |
US20080126869A1 (en) * | 2006-09-26 | 2008-05-29 | Microsoft Corporaion | Generating code to validate input data |
US20080222514A1 (en) * | 2004-02-17 | 2008-09-11 | Microsoft Corporation | Systems and Methods for Editing XML Documents |
US20080306992A1 (en) * | 2007-06-08 | 2008-12-11 | Hewlett-Packard Development Company, L.P. | Repository system and method |
US20090138462A1 (en) * | 2007-11-28 | 2009-05-28 | International Business Machines Corporation | System and computer program product for discovering design documents |
US20090138461A1 (en) * | 2007-11-28 | 2009-05-28 | International Business Machines Corporation | Method for discovering design documents |
US20090204884A1 (en) * | 2008-02-12 | 2009-08-13 | Oracle International Corporation | Multi-layer xml customization |
US20090204629A1 (en) * | 2008-02-12 | 2009-08-13 | Oracle International Corporation | Caching and memory optimizations for multi-layer xml customization |
US20090204567A1 (en) * | 2008-02-12 | 2009-08-13 | Oracle International Corporation | Customization syntax for multi-layer xml customization |
US20090265378A1 (en) * | 2008-04-21 | 2009-10-22 | Dahl Mark A | Managing data systems to support semantic-independent schemas |
US20100049732A1 (en) * | 2008-08-22 | 2010-02-25 | Disney Enterprises, Inc. (Burbank, Ca) | Method and system for managing data files and schemas |
US20100251099A1 (en) * | 2009-03-26 | 2010-09-30 | David Makower | Schema Validation for Submissions of Digital Assets for Network-Based Distribution |
US20100274851A1 (en) * | 2009-04-28 | 2010-10-28 | International Business Machines Corporation | Natural Ordering in a Graphical User Interface |
US20110119649A1 (en) * | 2009-11-18 | 2011-05-19 | Oracle International Corporation | Techniques for displaying customizations for composite applications |
US20130179769A1 (en) * | 2012-01-09 | 2013-07-11 | Oren GURFINKEL | Evaluation of differences between xml schemas |
US20130262523A1 (en) * | 2012-03-29 | 2013-10-03 | International Business Machines Corporation | Managing test data in large scale performance environment |
US8667031B2 (en) | 2008-06-13 | 2014-03-04 | Oracle International Corporation | Reuse of shared metadata across applications via URL protocol |
US8739026B2 (en) * | 2011-09-06 | 2014-05-27 | Hewlett-Packard Development Company, L.P. | Markup language schema error correction |
US8782604B2 (en) | 2008-04-11 | 2014-07-15 | Oracle International Corporation | Sandbox support for metadata in running applications |
US20140208290A1 (en) * | 2013-01-22 | 2014-07-24 | Oracle International Corporation | Application source code scanning for database migration |
US8799319B2 (en) | 2008-09-19 | 2014-08-05 | Oracle International Corporation | System and method for meta-data driven, semi-automated generation of web services based on existing applications |
US8875306B2 (en) | 2008-02-12 | 2014-10-28 | Oracle International Corporation | Customization restrictions for multi-layer XML customization |
US8898122B1 (en) * | 2011-12-28 | 2014-11-25 | Emc Corporation | Method and system for managing versioned structured documents in a database |
US8918379B1 (en) * | 2011-12-28 | 2014-12-23 | Emc Corporation | Method and system for managing versioned structured documents in a database |
US8954942B2 (en) | 2011-09-30 | 2015-02-10 | Oracle International Corporation | Optimizations using a BPEL compiler |
US8966465B2 (en) | 2008-02-12 | 2015-02-24 | Oracle International Corporation | Customization creation and update for multi-layer XML customization |
US8996658B2 (en) | 2008-09-03 | 2015-03-31 | Oracle International Corporation | System and method for integration of browser-based thin client applications within desktop rich client architecture |
US9002810B1 (en) * | 2011-12-28 | 2015-04-07 | Emc Corporation | Method and system for managing versioned structured documents in a database |
US9122520B2 (en) | 2008-09-17 | 2015-09-01 | Oracle International Corporation | Generic wait service: pausing a BPEL process |
US20180218026A1 (en) * | 2017-02-02 | 2018-08-02 | International Business Machines Corporation | Judgement of data consistency in a database |
US10223471B2 (en) | 2014-06-30 | 2019-03-05 | International Business Machines Corporation | Web pages processing |
US10394768B2 (en) * | 2017-08-07 | 2019-08-27 | Microsoft Technology Licensing, Llc | Selective data migration on schema breaking changes |
US10503787B2 (en) | 2015-09-30 | 2019-12-10 | Oracle International Corporation | Sharing common metadata in multi-tenant environment |
US10650080B2 (en) * | 2006-10-16 | 2020-05-12 | Oracle International Corporation | Managing compound XML documents in a repository |
US10762890B1 (en) * | 2019-08-19 | 2020-09-01 | Voicify, LLC | Development of voice and other interaction applications |
EP4018436A4 (en) * | 2019-08-19 | 2022-10-12 | Voicify, LLC | Development of voice and other interaction applications |
US11508365B2 (en) | 2019-08-19 | 2022-11-22 | Voicify, LLC | Development of voice and other interaction applications |
US11538466B2 (en) | 2019-08-19 | 2022-12-27 | Voicify, LLC | Development of voice and other interaction applications |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6540142B1 (en) * | 2001-12-17 | 2003-04-01 | Zih Corp. | Native XML printer |
US6643652B2 (en) * | 2000-01-14 | 2003-11-04 | Saba Software, Inc. | Method and apparatus for managing data exchange among systems in a network |
US6725231B2 (en) * | 2001-03-27 | 2004-04-20 | Koninklijke Philips Electronics N.V. | DICOM XML DTD/schema generator |
US6822663B2 (en) * | 2000-09-12 | 2004-11-23 | Adaptview, Inc. | Transform rule generator for web-based markup languages |
US6829745B2 (en) * | 2001-06-28 | 2004-12-07 | Koninklijke Philips Electronics N.V. | Method and system for transforming an XML document to at least one XML document structured according to a subset of a set of XML grammar rules |
US6908034B2 (en) * | 2001-12-17 | 2005-06-21 | Zih Corp. | XML system |
-
2003
- 2003-03-28 US US10/403,342 patent/US20040194016A1/en not_active Abandoned
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6643652B2 (en) * | 2000-01-14 | 2003-11-04 | Saba Software, Inc. | Method and apparatus for managing data exchange among systems in a network |
US6822663B2 (en) * | 2000-09-12 | 2004-11-23 | Adaptview, Inc. | Transform rule generator for web-based markup languages |
US6725231B2 (en) * | 2001-03-27 | 2004-04-20 | Koninklijke Philips Electronics N.V. | DICOM XML DTD/schema generator |
US6829745B2 (en) * | 2001-06-28 | 2004-12-07 | Koninklijke Philips Electronics N.V. | Method and system for transforming an XML document to at least one XML document structured according to a subset of a set of XML grammar rules |
US6540142B1 (en) * | 2001-12-17 | 2003-04-01 | Zih Corp. | Native XML printer |
US6908034B2 (en) * | 2001-12-17 | 2005-06-21 | Zih Corp. | XML system |
Cited By (95)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020059528A1 (en) * | 2000-11-15 | 2002-05-16 | Dapp Michael C. | Real time active network compartmentalization |
US20020066035A1 (en) * | 2000-11-15 | 2002-05-30 | Dapp Michael C. | Active intrusion resistant environment of layered object and compartment keys (AIRELOCK) |
US7080094B2 (en) * | 2002-10-29 | 2006-07-18 | Lockheed Martin Corporation | Hardware accelerated validating parser |
US20070016554A1 (en) * | 2002-10-29 | 2007-01-18 | Dapp Michael C | Hardware accelerated validating parser |
US20070061884A1 (en) * | 2002-10-29 | 2007-03-15 | Dapp Michael C | Intrusion detection accelerator |
US20040083221A1 (en) * | 2002-10-29 | 2004-04-29 | Dapp Michael C. | Hardware accelerated validating parser |
US20040083387A1 (en) * | 2002-10-29 | 2004-04-29 | Dapp Michael C. | Intrusion detection accelerator |
US20040172234A1 (en) * | 2003-02-28 | 2004-09-02 | Dapp Michael C. | Hardware accelerator personality compiler |
US20080222514A1 (en) * | 2004-02-17 | 2008-09-11 | Microsoft Corporation | Systems and Methods for Editing XML Documents |
US20060155725A1 (en) * | 2004-11-30 | 2006-07-13 | Canon Kabushiki Kaisha | System and method for future-proofing devices using metaschema |
US7882149B2 (en) * | 2004-11-30 | 2011-02-01 | Canon Kabushiki Kaisha | System and method for future-proofing devices using metaschema |
US20060230048A1 (en) * | 2005-04-08 | 2006-10-12 | International Business Machines Corporation | Method and apparatus for object discovery agent based mapping of application specific markup language schemas to application specific business objects in an integrated application environment |
US20060230063A1 (en) * | 2005-04-08 | 2006-10-12 | International Business Machines Corporation | Method and apparatus for mapping structured query language schema to application specific business objects in an integrated application environment |
US20060230066A1 (en) * | 2005-04-08 | 2006-10-12 | Yury Kosov | Using schemas to generate application specific business objects for use in an integration broker |
US8145653B2 (en) | 2005-04-08 | 2012-03-27 | International Business Machines Corporation | Using schemas to generate application specific business objects for use in an integration broker |
US8458201B2 (en) | 2005-04-08 | 2013-06-04 | International Business Machines Corporation | Method and apparatus for mapping structured query language schema to application specific business objects in an integrated application environment |
US20060277459A1 (en) * | 2005-06-02 | 2006-12-07 | Lemoine Eric T | System and method of accelerating document processing |
US20100162102A1 (en) * | 2005-06-02 | 2010-06-24 | Lemoine Eric T | System and Method of Accelerating Document Processing |
US7703006B2 (en) * | 2005-06-02 | 2010-04-20 | Lsi Corporation | System and method of accelerating document processing |
US20060294120A1 (en) * | 2005-06-27 | 2006-12-28 | Peng Li | Detecting migration differences of a customized database schema |
US7991742B2 (en) | 2005-06-27 | 2011-08-02 | International Business Machines Corporation | System for detecting migration differences of a customized database schema |
US20090119319A1 (en) * | 2005-06-27 | 2009-05-07 | International Business Machines Corporation | System for detecting migration differences of a customized database schema |
US7496596B2 (en) | 2005-06-27 | 2009-02-24 | International Business Machines Corporation | Detecting migration differences of a customized database schema |
US7774300B2 (en) | 2005-12-09 | 2010-08-10 | International Business Machines Corporation | System and method for data model and content migration in content management applications |
US20070136353A1 (en) * | 2005-12-09 | 2007-06-14 | International Business Machines Corporation | System and method for data model and content migration in content management application |
US7992081B2 (en) * | 2006-04-19 | 2011-08-02 | Oracle International Corporation | Streaming validation of XML documents |
US20070250766A1 (en) * | 2006-04-19 | 2007-10-25 | Vijay Medi | Streaming validation of XML documents |
US20080077848A1 (en) * | 2006-09-21 | 2008-03-27 | International Business Machines Corporation | Capturing and Processing Change Information in a Web-Type Environment |
US7895512B2 (en) * | 2006-09-21 | 2011-02-22 | International Business Machines Corporation | Capturing and processing change information in a web-type environment |
US7730028B2 (en) | 2006-09-22 | 2010-06-01 | Research In Motion Limited | Schema updating for synchronizing databases connected by wireless interface |
US20080077632A1 (en) * | 2006-09-22 | 2008-03-27 | Tysowski Piotr K | Schema updating for synchronizing databases connected by wireless interface |
US20080126869A1 (en) * | 2006-09-26 | 2008-05-29 | Microsoft Corporaion | Generating code to validate input data |
US7904963B2 (en) * | 2006-09-26 | 2011-03-08 | Microsoft Corporation | Generating code to validate input data |
US20080082963A1 (en) * | 2006-10-02 | 2008-04-03 | International Business Machines Corporation | Voicexml language extension for natively supporting voice enrolled grammars |
US7881932B2 (en) * | 2006-10-02 | 2011-02-01 | Nuance Communications, Inc. | VoiceXML language extension for natively supporting voice enrolled grammars |
US10650080B2 (en) * | 2006-10-16 | 2020-05-12 | Oracle International Corporation | Managing compound XML documents in a repository |
US20080092037A1 (en) * | 2006-10-16 | 2008-04-17 | Oracle International Corporation | Validation of XML content in a streaming fashion |
US11416577B2 (en) | 2006-10-16 | 2022-08-16 | Oracle International Corporation | Managing compound XML documents in a repository |
US20080306992A1 (en) * | 2007-06-08 | 2008-12-11 | Hewlett-Packard Development Company, L.P. | Repository system and method |
US7925636B2 (en) * | 2007-06-08 | 2011-04-12 | Hewlett-Packard Development Company, L.P. | Repository system and method |
US20090138462A1 (en) * | 2007-11-28 | 2009-05-28 | International Business Machines Corporation | System and computer program product for discovering design documents |
US7865488B2 (en) * | 2007-11-28 | 2011-01-04 | International Business Machines Corporation | Method for discovering design documents |
US7865489B2 (en) * | 2007-11-28 | 2011-01-04 | International Business Machines Corporation | System and computer program product for discovering design documents |
US20090138461A1 (en) * | 2007-11-28 | 2009-05-28 | International Business Machines Corporation | Method for discovering design documents |
US8875306B2 (en) | 2008-02-12 | 2014-10-28 | Oracle International Corporation | Customization restrictions for multi-layer XML customization |
US8966465B2 (en) | 2008-02-12 | 2015-02-24 | Oracle International Corporation | Customization creation and update for multi-layer XML customization |
US8788542B2 (en) * | 2008-02-12 | 2014-07-22 | Oracle International Corporation | Customization syntax for multi-layer XML customization |
US8538998B2 (en) | 2008-02-12 | 2013-09-17 | Oracle International Corporation | Caching and memory optimizations for multi-layer XML customization |
US20090204567A1 (en) * | 2008-02-12 | 2009-08-13 | Oracle International Corporation | Customization syntax for multi-layer xml customization |
US20090204629A1 (en) * | 2008-02-12 | 2009-08-13 | Oracle International Corporation | Caching and memory optimizations for multi-layer xml customization |
US8560938B2 (en) | 2008-02-12 | 2013-10-15 | Oracle International Corporation | Multi-layer XML customization |
US20090204884A1 (en) * | 2008-02-12 | 2009-08-13 | Oracle International Corporation | Multi-layer xml customization |
US8782604B2 (en) | 2008-04-11 | 2014-07-15 | Oracle International Corporation | Sandbox support for metadata in running applications |
US20090265378A1 (en) * | 2008-04-21 | 2009-10-22 | Dahl Mark A | Managing data systems to support semantic-independent schemas |
US8954474B2 (en) * | 2008-04-21 | 2015-02-10 | The Boeing Company | Managing data systems to support semantic-independent schemas |
US8667031B2 (en) | 2008-06-13 | 2014-03-04 | Oracle International Corporation | Reuse of shared metadata across applications via URL protocol |
US8209362B2 (en) * | 2008-08-22 | 2012-06-26 | Disney Enterprises, Inc. | Method and system for managing data files and schemas |
US20100049732A1 (en) * | 2008-08-22 | 2010-02-25 | Disney Enterprises, Inc. (Burbank, Ca) | Method and system for managing data files and schemas |
US9606778B2 (en) | 2008-09-03 | 2017-03-28 | Oracle International Corporation | System and method for meta-data driven, semi-automated generation of web services based on existing applications |
US8996658B2 (en) | 2008-09-03 | 2015-03-31 | Oracle International Corporation | System and method for integration of browser-based thin client applications within desktop rich client architecture |
US10296373B2 (en) | 2008-09-17 | 2019-05-21 | Oracle International Corporation | Generic wait service: pausing and resuming a plurality of BPEL processes arranged in correlation sets by a central generic wait server |
US9122520B2 (en) | 2008-09-17 | 2015-09-01 | Oracle International Corporation | Generic wait service: pausing a BPEL process |
US8799319B2 (en) | 2008-09-19 | 2014-08-05 | Oracle International Corporation | System and method for meta-data driven, semi-automated generation of web services based on existing applications |
US20100251099A1 (en) * | 2009-03-26 | 2010-09-30 | David Makower | Schema Validation for Submissions of Digital Assets for Network-Based Distribution |
US8312105B2 (en) * | 2009-04-28 | 2012-11-13 | International Business Machines Corporation | Natural ordering in a graphical user interface |
US20100274851A1 (en) * | 2009-04-28 | 2010-10-28 | International Business Machines Corporation | Natural Ordering in a Graphical User Interface |
US8856737B2 (en) | 2009-11-18 | 2014-10-07 | Oracle International Corporation | Techniques for displaying customizations for composite applications |
US20110119649A1 (en) * | 2009-11-18 | 2011-05-19 | Oracle International Corporation | Techniques for displaying customizations for composite applications |
US8869108B2 (en) | 2009-11-18 | 2014-10-21 | Oracle International Corporation | Techniques related to customizations for composite applications |
US8739026B2 (en) * | 2011-09-06 | 2014-05-27 | Hewlett-Packard Development Company, L.P. | Markup language schema error correction |
US8954942B2 (en) | 2011-09-30 | 2015-02-10 | Oracle International Corporation | Optimizations using a BPEL compiler |
US8898122B1 (en) * | 2011-12-28 | 2014-11-25 | Emc Corporation | Method and system for managing versioned structured documents in a database |
US9002810B1 (en) * | 2011-12-28 | 2015-04-07 | Emc Corporation | Method and system for managing versioned structured documents in a database |
US8918379B1 (en) * | 2011-12-28 | 2014-12-23 | Emc Corporation | Method and system for managing versioned structured documents in a database |
US20130179769A1 (en) * | 2012-01-09 | 2013-07-11 | Oren GURFINKEL | Evaluation of differences between xml schemas |
US8683323B2 (en) * | 2012-01-09 | 2014-03-25 | Hewlett-Packard Development Company, L.P. | Evaluation of differences between XML schemas |
US20130262523A1 (en) * | 2012-03-29 | 2013-10-03 | International Business Machines Corporation | Managing test data in large scale performance environment |
US9201911B2 (en) * | 2012-03-29 | 2015-12-01 | International Business Machines Corporation | Managing test data in large scale performance environment |
US9767141B2 (en) | 2012-03-29 | 2017-09-19 | International Business Machines Corporation | Managing test data in large scale performance environment |
US10664467B2 (en) | 2012-03-29 | 2020-05-26 | International Business Machines Corporation | Managing test data in large scale performance environment |
US9195691B2 (en) | 2012-03-29 | 2015-11-24 | International Business Machines Corporation | Managing test data in large scale performance environment |
US9189504B2 (en) * | 2013-01-22 | 2015-11-17 | Oracle International Corporation | Application source code scanning for database migration |
US20140208290A1 (en) * | 2013-01-22 | 2014-07-24 | Oracle International Corporation | Application source code scanning for database migration |
US10223471B2 (en) | 2014-06-30 | 2019-03-05 | International Business Machines Corporation | Web pages processing |
US10909186B2 (en) | 2015-09-30 | 2021-02-02 | Oracle International Corporation | Multi-tenant customizable composites |
US10503787B2 (en) | 2015-09-30 | 2019-12-10 | Oracle International Corporation | Sharing common metadata in multi-tenant environment |
US11429677B2 (en) | 2015-09-30 | 2022-08-30 | Oracle International Corporation | Sharing common metadata in multi-tenant environment |
US20180218026A1 (en) * | 2017-02-02 | 2018-08-02 | International Business Machines Corporation | Judgement of data consistency in a database |
US10685011B2 (en) * | 2017-02-02 | 2020-06-16 | International Business Machines Corporation | Judgement of data consistency in a database |
US10394768B2 (en) * | 2017-08-07 | 2019-08-27 | Microsoft Technology Licensing, Llc | Selective data migration on schema breaking changes |
US10762890B1 (en) * | 2019-08-19 | 2020-09-01 | Voicify, LLC | Development of voice and other interaction applications |
EP4018436A4 (en) * | 2019-08-19 | 2022-10-12 | Voicify, LLC | Development of voice and other interaction applications |
US11508365B2 (en) | 2019-08-19 | 2022-11-22 | Voicify, LLC | Development of voice and other interaction applications |
US11538466B2 (en) | 2019-08-19 | 2022-12-27 | Voicify, LLC | Development of voice and other interaction applications |
US11749256B2 (en) | 2019-08-19 | 2023-09-05 | Voicify, LLC | Development of voice and other interaction applications |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20040194016A1 (en) | Dynamic data migration for structured markup language schema changes | |
US7620936B2 (en) | Schema-oriented content management system | |
US6850893B2 (en) | Method and apparatus for an improved security system mechanism in a business applications management system platform | |
US7089583B2 (en) | Method and apparatus for a business applications server | |
US6721747B2 (en) | Method and apparatus for an information server | |
US7076786B2 (en) | State management of server-side control objects | |
US7539936B2 (en) | Dynamic creation of an application's XML document type definition (DTD) | |
US6643652B2 (en) | Method and apparatus for managing data exchange among systems in a network | |
US5418957A (en) | Network data dictionary | |
US7657832B1 (en) | Correcting validation errors in structured documents | |
US7730475B2 (en) | Dynamic metabase store | |
US6996589B1 (en) | System and method for database conversion | |
US9361390B2 (en) | Web content management | |
US20020049788A1 (en) | Method and apparatus for a web content platform | |
US7451394B2 (en) | System and method for document and data validation | |
WO2002059773A1 (en) | Modular distributed mobile data applications | |
JP2004503841A (en) | Method and system for reporting XML data from legacy computer systems | |
US7774386B2 (en) | Applying abstraction to object markup definitions | |
US7058939B2 (en) | Automatic link maintenance to ensure referential integrity constraints | |
US9501456B2 (en) | Automatic fix for extensible markup language errors | |
Leung | Professional XML Development with Apache Tools: Xerces, Xalan, FOP, Cocoon, Axis, Xindice | |
US20040168128A1 (en) | Connecting to WebDAV servers via the Java™ connector architecture | |
McIver Jr | A Database Wrapper Mechanism for Server-Side HTML-Embedded Scripting. | |
Jiang | Reengineering web applications to web-service providers |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:LIGGITT, JORDAN T.;REEL/FRAME:013935/0566 Effective date: 20030320 |
|
STCB | Information on status: application discontinuation |
Free format text: EXPRESSLY ABANDONED -- DURING EXAMINATION |