Source: https://patents.google.com/patent/US20080021916
Timestamp: 2018-05-23 20:36:30
Document Index: 650444035

Matched Legal Cases: ['Application No. 65470', 'Application No. 2323245', 'Application No. 507510', 'art 1002', 'art 1006', 'art 1004', 'art 1003', 'art 1007']

US20080021916A1 - Maintenance of a markup language document in a database - Google Patents
US20080021916A1
US20080021916A1 US11892907 US89290707A US2008021916A1 US 20080021916 A1 US20080021916 A1 US 20080021916A1 US 11892907 US11892907 US 11892907 US 89290707 A US89290707 A US 89290707A US 2008021916 A1 US2008021916 A1 US 2008021916A1
US11892907
This application claims priority of U.S. Provisional Patent Application Ser. No. 60/332253 filed on Nov. 16, 2001, the contents of which are incorporated herein by reference.
The present invention relates generally to electronic documents and, in particular, to the storage and maintenance of complex text-based documents.
International Publication No. WO 98/34179 (PCT/AU98/00050) in the name of Time Base Pty Ltd and published on 6 Aug. 1998 and counterpart U.S. Pat. No. 6,233,592 issued on 15 May 2001 to Schnelle et al. are incorporated herein by reference. In these documents, an electronic publishing system is disclosed that provides a sparse multidimensional matrix of data using a set of flat file records. In particular, the computer-implemented system publishes an electronic publication using text-based data. Predefined portions of the text-based data are stored and used for the publication. At least one of the predefined portions is modified, and the modified version is stored as well. The predefined portion is typically a block of text, greater in size than a single word, but less than an entire document. Thus, for example, in the case of legislation, the predefined portion may be a section of the Act. Each predefined portion and the modified portion(s) are marked up with one or more links using a markup language, preferably Standard Generalized Markup Language (SGML) or eXtensble Markup Language (XML). The system also has attributes, each being a point on an axis of a multidimensional space for organising the predefined portions and the modified portion(s) of the text-based data. This system is simply referred to as the Multi Access Layer Technology or “MALT” system hereinafter.
Australian Patent Application No. 65470/00 filed on 12 Oct. 2000 in the name of TimeBase Pty Ltd. Canadian Patent Application No. 2323245 filed on 12 Oct. 2000 in the name of TimeBase Pty Ltd, New Zealand Patent Application No. 507510 filed on 12 Oct. 2000 in the name of TimeBase Pty Ltd and U.S. patent application Ser. No. 09/689927 fled on 12 Oct. 2000 in the names of Fessing et al. are incorporated herein by reference.
Large or complex text-based datasets are typically hierarchical in nature. In the storage, maintenance and publication of such data, a ma language capable of describing such hierarchies is commonly used. XML is one such markup language that is more commonly used, particularly in the print, electronic or online publishing industries, and for government or public records or technical documentation XML data is stored typically either in “flat” text files encoded in ASCII, Unicode, or other standard text encoding, or in a “native” XML database.
The flat text files may be part of a document management system. Such a document management system may be based on a relational database. Document management systems deal with a document as a whole and are able to store relevant data about each document. However, document management systems are typically not designed to operate on data (XML elements) within such documents. Consequently, a document management system does not typically operate on all (or even a substantial number of the) XML elements contained in flat text files on which the document managing system is operating. An XML database, in contrast, operates on all XML elements of the XML data that the XML database is storing and, consequently, XML databases must manage large amounts of data and detail. As a result, document management systems have a limited usefulness resulting from a lack of precision, and XML databases are overwhelmed by the multiplicity of XML elements that are to be managed.
According to a third aspect of the present invention there is provided a computer program product having a computer readable median having a computer program recorded therein for converting a document encoded in a markup language into a format for mapping to a database table, the computer program product including:
a computer program code device for replacing the content of at least one node in the document stored in a first storage unit with a placeholder and storing the replaced content in a separate data storage unit associated with the corresponding node, the node to being an instance of a node element selected from a node element set; and
assigning the now DTD a public identifier that is the same as the public ID of the XML DTD except that the word MALTbase is inserted as a prefix to the descriptor;
According to an eighth aspect of the present invention there is provided a method for maintaining an eXtensible Markup Language (XML) document in MALTbase Structured Query Language (SQL) form, without the need for reconverting the document to XML the method comprising the steps of:
FIG. 6 c-f show sub-nodes of the root node of FIG. 6;
FIGS. 9 a-d illustrate the results of simple database operations an the node set of FIGS. 6 b-f;
A method, an apparatus and a computer program product for converting a markup language document into an equivalent database table are described. Preferably, the markup language is XML and the debase is a SQL database. In the following description, numerous details are set forth. It will be apparent to one skilled in the art, however, that the present invention may be practised without these specific details. In other instances, well-known features are not described in detail so as not to obscure the present invention. While the following description refers to an XML document, the principles embodied therein can readily be extended to encompass arbitrary collections of XML documents.
FIG. 1 shows a sample fragment of an XML document. Each XML document has exactly one root node, corresponding to content outside of the highest element of a node element set. The hierarchical structure present in the XML fragment might be represented by a node element set consisting of the node element names: chapter, part, section and note. A node is a portion of text corresponding to one of these node elements for the XML document. That is, the node is an instance of one of the node elements Accordingly, the “part” identified in FIG. 1 as “<part short_ref=Ch 3, Pt A”> is a node that has three sub-nodes: sections 56 and 56A and a note.
Each identified node in the XML document in turn requires a MALTbase identifier for further processing. A MALTbase node ID is constructed of a set of segments demarcated by a “/”, so that the ID of a sub-node contains the ID of the sub-node's parent as a prefix. Again, every XML document has exactly one root node. The root node always has a NULL node ID, and the content of the root node is trivial if the main document element is itself a node (which is typically the case). Thus, if the parent A) is /8/50/2/4, then a sub-node's ID might be /8/50/2/4/7. The final segment, “7”, is called the child ID of the sub-node.
The segments reflect the order of the sub-nodes within each parent node. These strings are ordered, so a sub-node inserted between child ID's ‘6’ and ‘7’ might have child ID ‘6.5’. For example, a new intermediate child ID maybe identified by a real number between the ID values of the upper and lower adjoining nodes m the node ordering. Other variations on this principle of generating intermediate node ID values may be practised without departing from the scope and spirit of the invention.
An XML document must be valid in relation to a DTD (or Schema—the logic is identical) for the original XML document to be maintained in a MALTbase system. In relation to the content of the original XML document, the content of each sub-node in the origin XML document is transferred to an independent sub-document. Modifications to the DTD are required to handle the MALTbase nodes. Every reference to the node in the DTD is (optionally) replaced by a placeholder. In the XML document, a placeholder replaces the content of a sub-node moved into the independent sub-document with a pointer to the respective independent sub-document containing the relevant sub-node.
Although technical descriptions in this document relate to DTDs, the principles described can readily be applied to XML Schemas and other markup language formal definitions for markup rules.
To transform an XML document into more manageable sub-documents, unique element names must be generated for the node element set. Extra elements must be inserted in the sub-documents to replace existing element names. It is vital that the new element names do not clash with names already in use. Fortunately, XML provides a means of doing this safely and efficiently.
The XML Namespace standard http://www.w3.org/TR/REC-xml-names) provides a mechanism for defining a distinct namespace in which the new elements can reside. This is achieved by inserting an identifying prefix and a colon separator before the existing element name, thus:
<MALTbase:chapter . . . \>.
xmlns:MALTbase CDATA #FIXED
“http://malt.com/xmlns/MALTbase”
In this way, each MALTbase element name or tag carries a corresponding namespace definition at all times. The word ‘MALTbase’ and the namespace ‘MALTbase:’ can be replaced by any suitable word and namespace.
A placeholder has the same element name as the original element name (“chapter”), except the placeholder's element name resides in the MALTbase namespace. Accordingly, “MALTbase:” is inserted as a prefix to the element name “chapter” to form “MALTbase:chapter”. A placeholder always has EMPTY content. An empty element is an element that does not contain further elements or data or text. A placeholder is an empty element.
The transformed DTD needs a modified public identifier to differentiate the modified DTD from the original DTD. A simple way to achieve this is to add the word is “MALTbase” to the beginning of the descriptive part of the ID. If the original DTD has a public ID:
“http://malt.com/xmlns/MALTbase”>.
The foregoing shows that not all elements (e.g., “desc”) need have a placeholder. In this example, “desc” and “label” are elements of the DTD, but are not in the node element set.
FIG. 2 shows an original DTD fragment 200 for the XML fragment of FIG. 1. The DTD fragment 200 contains a public ID 210 and element declarations 220, 230, 240, 250 and 260 for a chapter, part, section, note and desc, respectively. FIG. 3 shows a MALTbase version 300 of the DTD fragment of FIG. 2. In FIG. 3, the public ID 310 has evidently been modified to incorporate the word MALTbase as a prefix to the descriptor. FIG. 3 also shows the inclusion of a new element with empty content for each node element in the node element set of the document being converted. Thus, the element declaration 320 for a chapter has a corresponding element declaration 325 for a MALTbase:chapter. These are also new element declarations 335, 345 and 355 for MALTbase:part, MALTbase:section and MALTbase:note, respectively.
FIG. 4 b shows a modified DTD corresponding to the original DTD of FIG. 4 a Placeholder elements 410, 420, 430 have been inserted. The public id 440 has been modified to incorporate “MALTbase”. The content models have been modified such that there is an alternation between the original node elements and the modified node elements, as shown by 450 and 460. Even though level-1 does not appear in any content model, level-1 requires a placeholder so that it may appear in the root node if necessary.
After establishing a node element set and modifying the DTD, it is necessary to so decompose the original XML document into individual sub-documents corresponding to the individual nodes. Each sub-document must conform to the new DTD. The content of each node takes the form of a discrete sub-document where:
the full text of each sub-node is replaced by an empty element, which has a “MALTbase:” namespace prefix added to the sub-node element's name to distinguish the new MALTbase elements from their original counterparts, which can coexist in a single document when new nodes are created.
<!DOCTYPE document PUBLIC “-//TimeBase//DTD Sample//EN”>
<!DOCTYPE chapter PUBLIC “-//TimeBase//MALTbase DTD
Sample//EN”>
4. Replace any sub-node elements in the sub-documents with equivalent placeholders in which the namespace MALTbase: has been inserted as a prefix to the element name, and the only attribute explicit in the XML data is the child ID (the ID of the sub-node relative to all the other sub-nodes within the sub-node's parent). The additional xmlns:MALTbase attribute, defined in the transformed DTD as a #Fixed attribute, establishes a namespace that ensures that the new MALTbase; elements that are being inserted are unique and do not clash with any existing element. The element names must be unique to ensure that MALTbase is able to operate on any arbitrary XML document. So, if the part element also belongs to the node element set, then the internal fragment:
<part shortref=“Ch 3, Pt A”> . . . </part>
This enables sub-nodes to be abstracted. Thus, generally, one editor can operate on a part, and another editor can operate on a section within flat part without conflict. Accordingly, the original document can be divided into discrete chunks in such a way that if the integrity of each chunk is maintained then the integrity of the entire document is guaranteed. This is a powerful concept, since the need is removed to reverify a (potentially vast) document every time a chunk is changed.
Every document has exactly one root node. While every other node is associated with a single element in the node element set, the root node corresponds to the document as a whole. It is here that any XML content outside the outermost node(s) is kept. Where the DOCTYPE element is also a node element, the root node is trivial. For example, the document:
<note> . . . </p></note>
In FIG. 5 a, the root node of FIG. 1 has been converted to a MALTbase representation. In particular, the DOCTYPE declaration has been amended such that the DOCTYPE element “chapter” is now “MALTbase:chapter”. The chapter sub-node is moved into a separate node document For each node other than a terminal or leaf node, each MALTbase: element is effectively a sub-node placeholder that refers to a document that contains the sub-node. Terminal or leaf nodes do not contain placeholders, but instead have actual content from the original XML document. The root node of any XML document is not the principal DOCTYPE element, but a nameless node which contains all of the document outside the principal element. The principal element is the element corresponding to the highest level of the hierarchy of the XML document under consideration. The root node is typically trivial, unless the principal element is not itself a node. In the latter case, the root node may have some content from the original XML document.
PUBLIC “—//TimeBase Ltd//MALTbase DTD Sample Chapter//EN”
replaces the original descriptor
PUBLIC “—//TimeBase Ltd//DTD Sample Chapter//EN”
to differentiate the new DTD from the original DTD. The sub-node element is indicated by the expression
FIG. 5 b shows the converted MALTbase representation of Chapter 3 from FIG. 1. The MALTbase representation indicates that the DOCTYPE is a chapter and the word “MALTbase” has been added to the public identifier.
FIG. 1 shows that Chapter 3 consists of Part A and Part B. Accordingly, FIG. 5 b shows the sub-node elements <MALTbase:part child-id=“1”/> and <MALTbase:part child-id=“2”/>. The MALTbase representation of Chapter 3 concludes with the “link” line and the delimiter </chapter>. The child IDs shown above are purely arbitrary and are always assigned by the system, never by an end user.
FIG. 6 a shows a simple XML document conforming to the DTD of FIG. 4 a is FIGS. 6 b to 6 f show the decomposition of the document shown in FIG. 6 a. FIG. 6 b shows a resultant root node derived from the original document of FIG. 6 a. Since the DOCTYPE element is a node, the resultant root node 610 is trivial, containing in effect only the initial comment. The root node 610 is the only node, which may have a place holder as the DOCTYPE element.
FIG. 6 e shows the level-3 “baby” node 640 of the document of FIG. 6 a. The “baby” node 640 is a typical terminal node that has no children. Accordingly, this branch of the decomposition process is complete.
FIG. 6 f shows the level-2 “goldilocks” node 650 of the document of FIG. 6 a. The “goldilocks” node 650 is another terminal node and is structurally identical to the “baby” node 640 of FIG. 6 c.
Having created a number of sub-documents corresponding to each node, a SQL table must be established to allow the nodes to be stored and retrieved as desired. This table must include the following fields.
child_id—the child ID of the node being stored (information that corresponds to the node's relative position within the node's immediate parent);
Other fields may exist optionally in the table to expedite searching (e.g. a node_tag field to store the node element name: chapter, part, etc.; or a short_ref field to enable searching for nodes via the contents of a short_ref attribute).
The child ID is a value which conveys the position of a node with respect to its siblings (i.e. other nodes with the same pant). Each child of the same parent must therefore have a unique child ID. A helpful analogy is to regard the child ID as a decimal number. When a document is first converted, the first child of each parent node will be assigned child ID “1”, the next “2” and so on. If at some later time a new node is inserted between “1” and “2” then an ID such as “1.5” may be used. The exact values are unimportant, though it is desirable that the creation of extra “decimal places” be avoided where possible. The only guarantee is that: the child ID of a sibling occurring earlier in the document will always be less than the child ID of a sibling occurring later in the document. Note that child IDs may not necessarily be represented internally as decimal values, but they will always sort in the correct order.
As is evident from Table 1, the parent ID of any node is the fall ID of that node's parent, and the full ID of a node is the concatenation of the node's parent ID and child ID. Neither the parent ID nor the child ID of a node need be present in the node content. However, the child ID of a node is present in the content of that node's parent, as the child-id attribute of the corresponding placeholder.
The nodes table holds one node per record, and requires only three fields: parent_id, child_id and content. The content field is a (possibly quite large) text field or a Character Large OBject (CLOB) containing the converted node XML, or a unique pointer to that text in the sub-documents created during the document decomposition. To speed queries and updates it may be useful to include extra fields or even whole tables. Such additional extra fields and tables may include: XML context, unique and unalterable serial number, or an ancestry table.
FIG. 7 shows a minimal SQL node table 70 corresponding to the document fragment of FIG. 1. Each row in the node table 70 corresponds to a node. Each node has an associated child_id 72, a parent_id 74 and a content field 76. The content field 76 is a text string containing the MALTbase version of the relevant XML element. These string may be quite large, but a suitable choice of the node element set will ensure that they are sized appropriately for a particular application.
The node table 70 may in practice be augmented with extra fields to facilitate searching. Such additional fields may include XML element path or shortref. Similarly, a full ancestry table may be provided if rapid navigation through the hierarchy is a priority. Finally, the database technique of record locking can be simplified if each is record is assigned a unique, unchangeable serial number (unrelated to document order). A serial number does not change when, for example, two nodes are swapped. Record locking is the database facility which enables one user to update a record, and prevents any other user from attempting to update the same record until the first user is finished.
FIG. 8 shows a sample node table 800 arising from the decomposition shown in FIGS. 6 ato 6 f. Row 810 corresponds to the root node 610 of FIG. 6 b. The root node has a parent id of “NULL” and a child id of “NULL”. Row 820 corresponds to the “papa” node 620 of FIG. 6 c, having a parent id of “/” and a child id of 1. The child id of 1 indicates that the “papa” node is the first child of the root node 610. Row 830 corresponds to “mama” node 630 of FIG. 6 d, that has a parent id of “/1” and a child id of “1”. Similarly, row 840 corresponds to “baby” node 640 of FIG. 6 e that has a parent id of “/1/1” and a child id of “1”. Finally, row 850 corresponds to the terminal “goldilocks” node 650 of FIG. 6 f that has a parent id of “/1” and a child id of “2”. The child id of “2” indicates that the “goldilocks” node is the second child of the “papa” node 620. The child ID field must match the child ID attribute in the parent node.
WHERE parent_id=@current_node
isolating the sub-node element data (i.e. removing the XML instruction, DOCTYPE, and xmln:MALTbase attribute from the content field);
a setting the current node to be the sub-node;
<?MALTbase entity=“&ch3-pLA;” file=“ . . . /ch3/ptA.xml”?>
The decomposition of a large XML document into independent, smaller sub-documents is simply a means to an end. It is important to be able to access and modify the information in these sub-documents. A method, an apparatus and a computer program product for maintaining an XML document in MALTbase SQL form, without the need for reconverting the document to XML, are described.
locks the node for writing, and
the node's DOCTYPE, element
This operation is the most straightforward. Simply open the node, update the content, and save. The modify operation is the only operation performed on the target node itself. All other operations are performed on the parent of the node being inserted, deleted, etc.
At this point, the MALTbase system takes over. MALTbase routinely examines all updated nodes before saving the updated nodes. If MALTbase detects any node elements within a node, MALTbase will automatically decompose the node elements into as many new sub-nodes as are required, and replace the outermost sub-node with a placeholder. In effect, this is exactly the same process as was used to convert the original document, only limited to the content of a single node. This process cannot affect the validity of the master document, as the editing application will have validated the modified node prior to saving.
To delete a node, edit the node's parent and delete the appropriate placeholder. The editing application will ensure that such a deletion is valid. When saving the edited parent, the MALTbase system compares the list of child IDs with a list prepared by the system when the parent node was opened. If any placeholders are missing then the corresponding nodes (and any descendants) are deleted from the system. In this way, the validity of the whole document is maintained provided the validity of each individual node is preserved.
To copy a node, the node ID of the node to be copied must be known. Edit the node that will be the parent of the new copy, and insert a placeholder with an element name and child-id set to the ID of the node to be copied. If the node to be copied is not already a child of the parent, the full child ID is used, rather than just the final segment. The editing application will ensue that such an insertion is valid. When saving the edited parent, the MALTbase system will locate the nodes which have been amended in this way. A duplicate node will be created with identical content to the original, but with a parent ID set to the parent node that was edited. Any descendants will also be copied and be assigned new Ids, as appropriate, based on the parent ID and order amongst the node's existing child nodes.
It is not possible to create new nodes using this technique. Either an absolute or relative ID may be used. An absolute ID) begins with “/” and gives a full path down from the root node, whereas a relative ID begins with “./” and relates the child to the current parent. Absolute IDs are typically used except where the node to be copied is already a child of the new parent. The presence of the slash character in the child-id tells the system that an existing child node is not simply being relocated. Whatever form of child-id is used, the copy will be assigned a new regular child ID and the placeholders will be altered to reflect this.
has a placeholder referring to a nonexistent node;
has duplicate placeholders, except for those with child IDs beginning with “/” or “_/” (which imply a copy operation).
Simple Modify—the node content field is locked and the lock is released.
Deletion—write locks are obtained on the node to be deleted, and all descendants of that node. The mass deletion and write-back of the original parent node form a single transaction.
Copy—read locks are obtained on the node to be copied, and all descendants of that node. The mass copy, assignment of new IDs, and write-back of the target parent node form a single transaction.
Relocation—write locks are obtained on all affected child nodes, and all descendants of that node. Assignment of new IDs, and write-back of the original parent node form a single transaction.
The important thins that exclusive access to all the nodes being updated must be obtained before any part of the update can proceed. In this way, the linkage between placeholders and the corresponding node content is maintained and complex operations can proceed in parallel without threatening the integrity of the database.
Such considerations, however, we standard RDBMS practice and familiar to persons skilled in the art. The additional processes accompanying the write-back of a node into the database are of greater interest. To avoid potential confusion, the term principal node denotes the node that was modified and is being saved, and sub-node denotes one of the new or existing sub-nodes of the principal node. A placeholder is an empty MALTbase element that marks the location of a sub-node within the text of the principal node. The main steps involved in saving a modified principal node are as follows.
Generate a list of placeholders (if any) in the principal node. If any placeholder a does not correspond with an actual database node, an error arises.
Create the duplicate nodes (including descendants if any) and assign a provisional ID to each duplicate node. The ID consists of: the ID of the principal node, a provisional child ID within the principal node, and the trailing portion of the ID, if is the new node is a descendant of the node being copied.
If there are any sub-node elements (as opposed to placeholders) present, perform a standard MALTbase XML-to-SQL conversion on each such element and create new SQL records for each. Assign a provisional ID to each new node, assigning a provisional child ID within the principal node. Replace the text of each sub-node element in the principal node with a new placeholder.
A principal node now exists in which each placeholder corresponds to a unique new or existing sub-node, and all with provisional child IDs (except for existing sub-nodes which retain the previous ordering). The final step is to assign permanent child IDs to the placeholders, replacing the provisional segment in the ID of each corresponding sub-node (or descendant). The new IDs are normally chosen to evenly fill the range between the previous existing child ID (or “0” if none) and the following existing child ID (or “ffff . . . ”), using as few hex digits as possible.
1. The master document is reassembled prior to the change and the MALTbase version reconstructed after the change; and
The second requirement is that the DOCTYPE element of a sub-document cannot be freely altered. This is because, while the sub-document itself is validated by the XML editor, the new element type (and hence the new element type's matching placeholder) may not be valid within the parent node's content. If such a change is required, it must be performed as follows:
5. When the parent node is caved, the original child and, the original child's descendants will be deleted. Before this happens, any sub-nodes specified in step 4 (and such sub-nodes' descendants) will be copied. So in effect, an insert is performed, followed by a copy, followed by a delete.
The above technique will work even in the unlikely event that the new element type is not itself a node element. Any attempt to alter a node simply by changing the node's DOCTYPE element will be blocked by the system which stores the DOCTYPE of each node before the node is edited.
The final constraint is that the node element set cannot be altered for a MALTbase document. If the node elements do need to be adjusted, then the master document must be reassembled. The master document can tend be decomposed back into MALTbase form using the new node element set.
1. Generate a list of placeholders: 1, /8/C/3b/2, a, 7, a, d These placeholders are the child-ids of the parts and the note of the modified node 1000 a;
3. Generate a list of unmatched sub-nodes: 4. Any such sub-node and each such sub-node's associated descendants are deleted. In this case, the second part 1002 of FIG. 10 a, having a child-id of “4”, is deleted, along with any of the second part's descendants; and
4. Generate a list of unmatched placeholders: /8/c/3b/2, a. Any such nodes having unmatched placeholders are duplicated, along with any associated descendants, and provisional IDs are assigned to the duplicated nodes.
FIG. 10 c shows the further modified node 1000 b in which provisional IDs have been assigned to each of the new fifth part 1006 and fourth part 1004. FIG. 10 d shows the allocation of provisional IDs to any placeholder that is out of order. In this instance, the third part 1003 having a child-id of “7” is deemed to be out of order and a new provisional id of “x3” is assigned.
FIG. 10 e shows the conversion of any sub-node elements and the replacement of placeholders. The new fifth part 1007 is assigned an id of “x4”.
One of the greatest benefits of this system is that the nodes are created in such a way that: if you ensure the validity of each node, then the validity of the entire document is guaranteed. It is difficult to overstate the importance of this point, since this feature allows a user to update a single node in isolation. Provided a user's updates leave the node valid against the DTD (as all good XML editors should), then the user can be confident that the larger document as a whole will also be valid, without having to examine anything outside the scope of the node's being modified.
Typically, the application program is resident on the hard disk drive 1110 and read and controlled in its execution by the processor 1105. Intermediate storage of the program and any data fetched from the network 1120 may be accomplished using the semiconductor memory 1106, possibly in concert with the hard disk drive 1110. In some instances, the application program may be supplied to the user encoded on a CD-ROM or floppy disk and read via the corresponding drive 1112 or 1111, or alternatively may be read by the user from the network 1120 via the modem device 1116. Still further, the software can also be loaded into the computer system 1100 from other computer readable media. The term “computer readable medium” as used herein refers to any storage or transmission medium that participates in providing instructions and/or data to the computer system 1100 for execution and/or processing. Examples of storage media include floppy disks, magnetic tape, CD-ROM, a hard disk drive, a ROM or integrated circuit, a magneto-optical disk, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the computer module 1101. Examples of transmission media include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including email transmissions and information recorded on websites and the like.
an identifier that indicates a position of a respective node relative to any other children of a patent node of said respective node.
replacing the text of each sub-node element in said principal node with a now placeholder; and
an identifier that indicates a position of a respective node relative to any other to children of a parent node of said respective node.
an identifier that indicates a position of a respective node relative to any other is children of a parent node of said respective node.
means for creating a database table having a record for each respective node, wherein each said record includes fields corresponding to an identifier of said node, an identifier of a parent node of said respective node and content associated with said respective node.
32. The apparatus according to claim 30, further including:
means for assigning a provisional identifier to each duplicate node, wherein each identifier consists of an identifier associated with said principal is node, a provisional child identifier within said principal node, and a trailing portion, if said modified node is a descendant of a node being copied;
means for assigning a provisional child identifier within said principal node;
means for replacing the text of each sub-node element in said principal node with a now placeholder; and
33. A computer program product having a computer readable medium having a computer program recorded therein for converting a document encoded in a markup language into a format for mapping to a database table, said computer program product including:
computer program code means for inserting a command for identifying the associated rules for the markup language having an element corresponding to said node element of which said respective node is an stance, and a public identifier that is distinct and derived from that of said formal definition of markup rules associated with said document to create a new formal definition of markup rules;
determining one or more nodes of said XML encoded document, each node being an instance of a node element;
assembling the XML content of each node by performing the flyer steps of:
replacing any sub-node elements with equivalent empty placeholder elements in which the namespace MALTbase: has been inserted as a prefix to a element name, wherein the only non-fixed attribute is a child ID, being the ID of the sub-node relative to all other sub-nodes within the sub-node's parent; end
50. A method for converting an eXtensible Markup Language (XML) Document Type Definition (DTD) into a form suitable for accessing preprocessed node content, said method comprising the steps of:
51. A method for converting an eXtensible Markup Language (XML) Document Type Definition (DTD) into a form suitable for accessing pre-processed node content, said method comprising the steps of:
creating a new placeholder element for every element in the node element set, each said placeholder element having MALTbase: inserted as a prefix to the name; an empty content model; and an ATTLIST containing the two attributes:
55. The method according to claim 54 wherein said edit function is chosen from the group consisting of: modifying an existing node; deleting an existing node (or sub-tree); copying an existing node (or sub-tree) to a new location; creating a new node (or sub-tree); reordering child nodes within a single parent; or any combination of the preceding actions.
US11892907 2001-11-16 2007-08-28 Maintenance of a markup language document in a database Abandoned US20080021916A1 (en)
US33225301 true 2001-11-16 2001-11-16
US10294384 US7281206B2 (en) 2001-11-16 2002-11-14 Maintenance of a markup language document in a database
US11892907 US20080021916A1 (en) 2001-11-16 2007-08-28 Maintenance of a markup language document in a database
US20080021916A1 true true US20080021916A1 (en) 2008-01-24
US10294384 Active 2024-01-29 US7281206B2 (en) 2001-11-16 2002-11-14 Maintenance of a markup language document in a database
US11892907 Abandoned US20080021916A1 (en) 2001-11-16 2007-08-28 Maintenance of a markup language document in a database
US20140026117A1 (en) * 2012-07-18 2014-01-23 International Business Machines Corporation Source Control Execution Path Locking
US20180052808A1 (en) * 2016-08-16 2018-02-22 Adobe Systems Incorporated Creation and display of a webpage with alternative layouts for different webpage widths
CN102508840A (en) * 2010-09-09 2012-06-20 微软公司 Concurrent editing of online drawings
US9058339B2 (en) * 2012-07-18 2015-06-16 International Business Machines Corporation Source control inheritance locking
US20140025653A1 (en) * 2012-07-18 2014-01-23 International Business Machines Corporation Source Control Inheritance Locking
US7281206B2 (en) 2007-10-09 grant
US20030177443A1 (en) 2003-09-18 application
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SCHNELLE, CHRISTOPH;NOLAN, GEOFFREY JOHN;REEL/FRAME:019796/0880