WO2002059726A2 - Procede permettant d'effectuer la recherche d'un modele objet de document numerique - Google Patents

Procede permettant d'effectuer la recherche d'un modele objet de document numerique Download PDF

Info

Publication number
WO2002059726A2
WO2002059726A2 PCT/US2002/000719 US0200719W WO02059726A2 WO 2002059726 A2 WO2002059726 A2 WO 2002059726A2 US 0200719 W US0200719 W US 0200719W WO 02059726 A2 WO02059726 A2 WO 02059726A2
Authority
WO
WIPO (PCT)
Prior art keywords
dictionary
data
tag
string
offset
Prior art date
Application number
PCT/US2002/000719
Other languages
English (en)
Other versions
WO2002059726A3 (fr
Inventor
Christopher Lockton Brandin
Kevin Lawrence Huck
Linda Lee Grimaldi
Original Assignee
Neo-Core
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Neo-Core filed Critical Neo-Core
Priority to AU2002241843A priority Critical patent/AU2002241843A1/en
Publication of WO2002059726A2 publication Critical patent/WO2002059726A2/fr
Publication of WO2002059726A3 publication Critical patent/WO2002059726A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/42—Syntactic analysis
    • G06F8/427—Parsing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/901—Indexing; Data structures therefor; Storage structures
    • G06F16/9017—Indexing; Data structures therefor; Storage structures using directory or table look-up
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99931—Database or file accessing
    • Y10S707/99933—Query processing, i.e. searching
    • Y10S707/99936—Pattern matching access
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99941—Database schema or data structure
    • Y10S707/99942—Manipulating data structure, e.g. compression, compaction, compilation
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99941—Database schema or data structure
    • Y10S707/99943—Generating database or data structure, e.g. via user interface

Definitions

  • the present invention relates generally to the field of structured data documents and more particularly to a method of performing a 25 search of a numerical document object model (DOM).
  • DOM numerical document object model
  • Structured data documents such as HTML (Hyper Text Markup Language), XML (extensible Markup Language) and SGML (Standard Generalized Markup Language) documents and derivatives use tags to describe the data associated with the tags. This has an advantage over databases in that not all the fields are required to be predefined.
  • XML is presently finding widespread interest for exchanging information between businesses. XML appears to provide an excellent solution for internet business to business applications. Unfortunately, XML documents require a lot of memory and therefore are time consuming and difficult to search.
  • FIG. 1 is an example of an XML document in accordance with one embodiment of the invention
  • FIG. 2 is an example of a flattened data document in accordance with one embodiment of the invention
  • FIG. 3 is a block diagram of a system for storing a flattened data document in accordance with one embodiment of the invention
  • FIG. 4 shows two examples of a map store cell in accordance with one embodiment of the invention
  • FIG. 5 is a flow chart of a method of storing a structured data document in accordance with one embodiment of the invention.
  • FIG. 6 is a flow chart of a method of storing a structured data document in accordance with one embodiment of the invention
  • FIG. 7 is a flow chart of a method of storing a structured data document in accordance with one embodiment of the invention
  • FIG. 8 is a block diagram of a system for storing a flattened structured data document in accordance with one embodiment of the invention
  • FIG. 9 is a block diagram of a system for storing a flattened structured data document in accordance with one embodiment of the invention.
  • FIG. 10 is a flow chart of the steps used in a method of storing a flattened structured data document in accordance with one embodiment of the invention.
  • FIG. 11 is a flow chart of the steps used in a method of storing a flattened structured data document in accordance with one embodiment of the invention.
  • FIG. 12 is a schematic diagram of a method of storing a numerical document object model in accordance with one embodiment of the invention
  • FIG. 13 shows several examples of search queries of a numerical document object model in accordance with one embodiment of the invention
  • FIG. 14 is a flow chart of the steps used in a method of performing a search of a numerical document object model in accordance with one embodiment of the invention.
  • FIG. 15 is a flow chart of the steps used in a method of performing a search of a numerical document object model in accordance with one embodiment of the invention
  • FIG. 16 is a flow chart of the steps used in a method of translating a structured data document in accordance with one embodiment of the invention.
  • FIG. 17 is a flow chart of the steps used in a method of creating an alias in a numerical document object model in accordance with one embodiment of the invention.
  • a method of performing a search of a numerical DOM includes the steps of receiving a query.
  • the query is a fully qualified query
  • the target is transformed to form a fully qualified icon.
  • An associative lookup is performed in a map index using the fully qualified icon.
  • a map offset is returned.
  • the map offset points to a couplet that can be converted into a standard portion of a structured data document. Since the structured data document has been converted into a numerical DOM, it requires significantly less memory to store. This significantly reduces the time to search the document. In addition, once the document has been converted into a numerical DOM it is no longer necessary to look at the underlying document to perform a search.
  • FIG. 1 is an example of an XML document 10 in accordance with one embodiment of the invention.
  • the words between the ⁇ ⁇ > are tags that describe the data.
  • This document is a catalog 12. Note that all tags are opened and later closed. For instance ⁇ catalog> 12 is closed at the end of the document ./catalogs 14.
  • the first data item is "Empire Burlesque" 16.
  • the tags ⁇ CD> 18 and ⁇ TITLE> 20 tell us that this is the title of the CD (Compact Disk).
  • the next data entry is "Bob Dylan" 22, who is the artist. Other compact disks are described in the document.
  • FIG. 2 is an example of a flattened data document (numerical document object model) 40 in accordance with one embodiment of the invention.
  • the first five lines 42 are used to store parameters about the document.
  • the next line (couplet) 44 shows a line that has flattened all the tags relating to the first data entry 16 of the XML document 10. Note that the tag ⁇ ND> 46 is added before every line but is not required by the invention.
  • the next tag is CATALOG ⁇ 46 which is the same as in the XML document 10.
  • the tag CD> 48 is shown and finally the tag TITLE> 50. Note this is the same order as the tags in the XML document 10.
  • a plurality of formatting characters 52 are shown to the right of each line.
  • the first column is the n-tag level 54. The n-tag defines the number of tags that closed in that line.
  • first line 44 which ends with the data entry "Empire Burlesque" 16, has a tag 24 (FIG. 1) that closes the tag TITLE.
  • the next tag 26 opens the tag ARTIST.
  • the n-tag for line 44 is a one.
  • line 60 has an n-tag of two. This line corresponds to the data entry 1985 and both the YEAR ' and the CD tags are closed.
  • the next column 56 has a format character that defines whether the line is first (F) or another line follows it (N-next) or the line is the last (L).
  • the next column contains a line type definition 58. Some of the line types are: time stamp (S); normal (E); identification (I); attribute (A); and processing (P).
  • the next column 62 is a delete level and is enclosed in a parenthesis.
  • a delete command is received the data is not actually erased but is eliminated by entering a number in the parameters in a line to be erased. So for instance if a delete command is received for "Empire Burlesque" 16, a "1" would be entered into the parenthesis of line 44. If a delete command was received for "Empire Burlesque” 16 and ⁇ TITLE>, ⁇ /TITLE>, a "2" would be entered into the parenthesis.
  • the next column is the parent line 64 of the current line.
  • the parent line for the line 66 is the first line containing the tag CATALOG.
  • the last column of formatting characters is a p- level 68.
  • the p-level 68 is the first new tag opened but not closed.
  • the first new tag opened is CATALOG.
  • the tag CATALOG is not closed.
  • the p-level is two (2).
  • FIG. 3 is a block diagram of a system 100 for storing a flattened data document in accordance with one embodiment of the invention.
  • the structured data document Once the structured data document is flattened as shown in FIG. 2, it can be stored.
  • Each unique tag or unique set of tags for each line is stored to a tag and data store 102.
  • the first entry in the tag and data store is ND>CATALOG>CD>TITLE> 104.
  • the data entry "Empire Burlesque" 106 is stored in the tag and data store 102.
  • the pointers to the tag and data entry in the tag and data store 102 are substituted into line 44. Updated line 44 is then stored in a first cell 108 of the map store 110.
  • the tag store and the data store are separate.
  • the tag and data store 102 acts as a dictionary, which reduces the required memory size to store the structured data document. Note that the formatting characters allow the structured data document to be completely reconstructed.
  • FIG. 4 shows two examples of a map store cell in accordance with one embodiment of the invention.
  • the first example 120 works as described above.
  • the cell (couplet) 120 has a first pointer (P ( ) 122 that points to the tag in the tag and data store 102 and a second pointer (P 2 ) 124 that points to the data entry.
  • the other information is the same as in a flattened line such as: p-level 126; n-tag 128; parent 130; delete level 132; line type 134; and line control information 136.
  • the second cell type 140 is for an insert. When an insert command is received a cell has to be moved. The moved cell is replaced with the insert cell 140.
  • the insert cell has an insert flag 142 and a jump pointer 144. The moved cell and the inserted cell are at the jump pointer.
  • FIG. 5 is a flow chart of a method of storing a structured data document.
  • the process starts, step 150, by receiving the structured data document at step 152.
  • a first data entry is determined at step 154.
  • the first data entry is an empty data slot.
  • a first plurality of open tags and the first data entry is stored which ends the process at step 158.
  • a level of a first opened tag is determined.
  • the level of the first opened tag is stored.
  • a number of consecutive tags closed after the first data entry is determined. This number is then stored.
  • a line number is stored.
  • a next data entry is determined.
  • a next plurality of open tags preceeding the next data entry is stored. These steps are repeated until a next data entry is not found.
  • the first data entry may be a null.
  • a plurality of format characters associated with the next data entry are also stored.
  • the flattened data document is expanded into the structured data document using the plurality of formatting characters.
  • FIG. 6 is a flow chart of a method of storing a structured data document. The process starts, step 170, by flattening the structured data document to a provide a plurality of tags, a data entry and a plurality of format characters in a single line at step 172.
  • the plurality of tags, the data entry and the plurality of format characters are stored which ends the process at step 176.
  • the plurality of tags are stored in a tag and data store.
  • the plurality of format characters are stored in map store.
  • the data entry is stored in the tag and data store.
  • a first pointer in the map store points to the plurality of tags in the tag and data store.
  • a second pointer is stored in the map store that points to the data store.
  • the structured data document is received.
  • a first data entry is determined.
  • a first plurality of open tags proceeding the first data entry and the first data entry are placed in a first line.
  • a next data entry is determined.
  • a next plurality of open tags proceeding the next data entry is placed in the next line.
  • a format character is placed in the first line.
  • the format character is a number that indicates a level of a first tag that was opened.
  • the format character is a number that indicates a number of tags that are consecutively closed after the first data entry.
  • the format character is a number that indicates a line number of a parent of a lowest level tag.
  • the format character is a number that indicates a level of a first tag that was opened but not closed.
  • the format character is a character that indicates a line type.
  • the format character indicates a line control information.
  • the structured data document is an extensible markup language document.
  • the next data entry is placed in the next line.
  • FIG. 7 is a flow chart of a method of storing a structured data document.
  • the process starts, step 180, by flattening the structured data document to contain in a single line a tag, a data entry and a formatting character at step 182.
  • the formatting character is stored in a map store at step 184.
  • the tag and the data entry are stored in a tag and data store which ends the process at step 188.
  • a first pointer is stored in the map store that points to the tag in the tag and data store.
  • a second pointer is stored in the map store that points to the data entry in the tag and data store.
  • a cell is created in the map store for each of the plurality of lines in a flattened document.
  • a request is received to delete one of the plurality of data entries.
  • the cell associated with the one of the plurality of data entries is determined.
  • a delete flag is set. Later a restore command is received. The delete flag is unset.
  • a request to delete one of a plurality of data entries and a plurality of related tags is received.
  • a delete flag is set equal to the number of the plurality of related tags plus one.
  • a request is received to insert a new entry.
  • a previous cell containing a proceeding data entry is found.
  • the new entry is stored at an end of the map store.
  • a contents of the next cell is moved after the new entry.
  • An insert flag and a pointer to the new entry is stored in the next cell.
  • a second insert flag and second pointer is stored after the contents of the next cell.
  • FIG. 8 is a block diagram of a system 200 for storing a flattened structured data document (numerical DOM) in accordance with one embodiment of the invention.
  • the system 200 has a map store 202, a dictionary store 204 and a dictionary index 206.
  • the dictionary store 204 has essentially the same function as the map and tag store (FIG. 3) 102. The difference is that a dictionary index 206 has been added.
  • the dictionary index 206 is an associative index.
  • An associative index transforms the item to be stored, such as a tag, tags or data entry, into an address. Note that in one embodiment the transform returns an address and a confirmer as explained in the United States patent application, Serial No. 09/419,217, entitled “Memory Management System and Method” filed on October 15, 1999, assigned to the same assignee as the present application and hereby incorporated by reference.
  • FIG. 9 is a block diagram of a system 220 for storing a flattened structured data document (numerical DOM) in accordance with one embodiment of the invention.
  • a structured data document 222 is first processed by a flattener 224.
  • the flattener 224 performs the functions described with respect to FIGs. 1 & 2 to form a numerical DOM.
  • a parser 226 determines the data entries and the associated tags.
  • FIG. 10 is a flow chart of the steps used in a method of storing a flattened structured data document (numerical DOM) in accordance with one embodiment of the invention. The process starts, step 240, by flattening the structured data document to form a flattened structured data document (numerical DOM) at step 242.
  • Each line of the flattened structured data document is parsed for a tag at step 244.
  • the tag is stored in a dictionary store which ends the process at step 250.
  • a tag dictionary offset is stored in the map store.
  • a plurality of format characters are stored in the map store.
  • a tag dictionary offset is determined.
  • the tag dictionary offset is stored in the map store.
  • the tag is transformed to form a tag transform.
  • An associative lookup is performed in a dictionary index using the tag transform.
  • a map index is created that has a map pointer that points to a location in the map store of the tag.
  • the map pointer is stored at an address of the map index that is associated with the tag transform.
  • FIG. 11 is a flow chart of the steps used in a method of storing a flattened structured data document (numerical DOM) in accordance with one embodiment of the invention.
  • the process starts, step 260, by receiving the flattened structured data document (numerical DOM) that has a plurality of lines (couplets) at step 262.
  • Each of the plurality of lines contains a tag, a data entry and a format character.
  • the tag is stored in a dictionary store at step 264.
  • the data entry is stored in the dictionary store at step 266.
  • the format character, a tag dictionary offset and a data dictionary offset are stored in a map store which ends the process at step 270.
  • the tag is transformed to form a tag transform.
  • the tag dictionary offset is stored in a dictionary index at an address pointed to by the tag transform. In one embodiment, it is determined if the tag is unique. When the tag is unique, the tag is stored in the dictionary store otherwise the tag is not stored (again) in the dictionary store. To determine if the tag is unique, it is determined if a tag pointer is stored in the dictionary index at an address pointed to by the tag transform.
  • the data entry is transformed to form a data transform.
  • the data dictionary offset is stored in the dictionary index at an address pointed to by the data transform.
  • each of the flattened lines has a plurality of tags.
  • a map index is created. Next it is determined if the tag is unique. When the tag is unique, a pointer to a map location of the tag is stored in the map index. When the tag is not unique, it is determined if a duplicates flag is set. When the duplicates flag is set, a duplicates count is incremented. When the duplicates flag is not set, the duplicates flag is set. The duplicates count is set to two.
  • a transform of the tag with an instance count is calculated to form a first instance tag transform and a second instance tag transform. A first map pointer is stored in the map index at an address associated with the first instance transform. A second map pointer is stored in the map index at an address associated with the second instance transform.
  • a transform of the tag with an instances count equal to the duplicates count is calculated to form a next instance tag transform.
  • a next map pointer is stored in the map index at an address associated with the next instance transform.
  • a map index is created. Next it is determined if the data entry is unique. When the data entry is unique, a pointer to a map location of the tag is stored.
  • FIG. 12 is a schematic diagram of a method of storing a numerical document object model in accordance with one embodiment of the invention. This is similar to the models described with respect to FIGs. 3 & 8.
  • the couplets (flattened lines) are stored in the map store 302.
  • a tag dictionary 304 stores a copy of each unique tag string. For instance, the tag string
  • CATALOG>CD>TITLE> 306 from line 44 (see FIG. 2) is stored in the tag dictionary 304.
  • the tag ND> is associated with every line and therefor has been ignored for this discussion.
  • a tag dictionary index 308 is created. Every tag, incomplete tag string and complete tag string is indexed. As a result the tag CATALOG) 310,
  • a data dictionary 314 stores a copy of each unique data entry such as "Bob Dylan".
  • a data dictionary index 316 associates each data entry with its location in the dictionary.
  • the tag dictionary index and the data dictionary index are associative memories.
  • a mathematical transformation of the entry such as "Bob Dylan” provides the address in the index where a pointer to the entry is stored.
  • a map index 318 is created.
  • the map index 318 contains an entry for every complete tag string (see string 306) and the complete tag sting and associated data entry. Note that the map index may be an associative index.
  • FIG. 13 shows several examples of search queries of a numerical document object model in accordance with one embodiment of the invention.
  • the first example 330 is a fully qualified query since a complete tag string has been specified.
  • the second example 332 is also a fully qualified query since a complete tag string and a complete data entry have been specified.
  • the third example is a not fully qualified query since a partially complete tag string has been specified.
  • the fourth 336 and fifth 338 examples are also examples of a not fully qualified query since the data entry is not complete. Note that the * stands for any wild card. If the data entry were completely specified, the query would be fully qualified.
  • FIG. 14 is a flow chart of the steps used in a method of performing a search of a numerical document object model in accordance with one embodiment of the invention.
  • the process starts, step 350, by receiving a query at step 352.
  • the target is transformed to form a fully qualified icon at step 354.
  • the phrase "fully qualified icon” means the icon for the target of a fully qualified query.
  • An icon is a mathematical transformation of the target to produce an address and a confirmer as explained in the United States patent application, Serial No. 09/419,217, entitled “Memory Management System and Method” filed on October 15, 1999, assigned to the same assignee as the present application and hereby incorporated by reference.
  • An associative lookup in a map index is performed using the fully qualified icon at step 356.
  • a map offset is returned which ends the process at step 360.
  • an identified couplet of the numerical DOM (as stored in the map) is converted into an XML string.
  • the query is not fully qualified, it is determined if the target is a complete data string.
  • the complete data string is transformed to form a complete data icon.
  • An associative lookup is performed in a dictionary index using the complete data icon.
  • a dictionary offset is returned.
  • the numerical DOM is scanned for the dictionary offset and a data couplet is returned.
  • the data couplet is converted into a data XML string.
  • the target is an incomplete data string.
  • the target is the incomplete data string
  • a sliding window search of the dictionary is performed.
  • a dictionary offset of a match is returned.
  • the numerical DOM is scanned for the dictionary offset.
  • An incomplete data couplet is returned. Note the phrase "incomplete data couplet" is a couplet identified by the incomplete data target. In one embodiment the incomplete data couplet is converted into an incomplete data XML string.
  • the sliding window search includes transforming the incomplete data string to form an incomplete data string icon in one embodiment.
  • a match array is created next.
  • a match flag is stored at an address pointed to by the incomplete data string icon.
  • a sliding transform is performed across the data dictionary.
  • a lookup is performed in the match array for each of a plurality of test icons. Note that the match array is particularly effective when multiple data strings are being searched for simultaneously.
  • the incomplete tag string is transformed to form an incomplete tag icon.
  • An associative lookup is performed in a map index using the incomplete tag icon.
  • a map offset is returned.
  • FIG. 15 is a flow chart of the steps used in a method of performing a search of a numerical document object model in accordance with one embodiment of the invention.
  • the process starts, step 370, by receiving a query at step 372.
  • a target type of the query is determined at step 374.
  • a sliding window search of a dictionary is performed at step 376.
  • a dictionary offset of a match is returned at step 378.
  • a plurality of dictionary offsets are returned.
  • the numerical DOM is scanned for the dictionary offset at step 380.
  • an incomplete data couplet is returned which ends the process at step 384.
  • the target type is an incomplete tag and a complete data string, the incomplete tag is transformed to form an incomplete target icon.
  • An associative lookup in a map index is performed using the incomplete tag icon. When a match is found, at least one map offset is returned. The complete data string is transformed to form a complete data string icon. An associative lookup is performed in the dictionary. A dictionary offset is returned when there is a match. Next it is determined for each couplet associated with each of the at least one map offset if it contains the dictionary offset. Any couplet that contains the dictionary offset is returned .
  • FIG. 16 is a flow chart of the steps used in a method of translating a structured data document in accordance with one embodiment of the invention.
  • step 390 by creating a numerical DOM of the structured data document at step 392.
  • a first format dictionary is translated into a second format dictionary at step 394.
  • step 396 a second set of dictionary pointers are added to the dictionary index.
  • the second set of dictionary pointers point to the offsets in the second format dictionary which ends the process at step 398.
  • a plurality of dictionary offset pointers are converted to a plurality of dictionary index pointers. This converts the map so it points to the dictionary index rather than the offsets into the dictionary, since there are two dictionaries now.
  • FIG. 17 is a flow chart of the steps used in a method of creating an alias in a numerical document object model in accordance with one embodiment of the invention.
  • the process starts, step 410, by receiving an alias request at step 412.
  • a dictionary offset for the original string in a dictionary is found at step 414.
  • the original string is converted to the alias at the dictionary offset which ends the process at step 418.
  • An alias index is created that associates the alias and the original string or the dictionary offset of the original string.
  • the original string is transformed to form a string icon.
  • An associative lookup in the dictionary is performed to find the dictionary offset.
  • the methods described herein can be implemented as computer- readable instructions stored on a computer-readable storage medium that when executed by a computer will perform the methods described herein.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Mining & Analysis (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne un procédé permettant d'effectuer la recherche d'un Modèle Objet de Document (DOM) numérique, consistant à recevoir une demande. Lorsque la demande est une demande entièrement qualifiée, la cible est transformée, de sorte à former une icône entièrement qualifiée. Une consultation de table associative est exécutée dans une carte index au moyen de l'icône entièrement qualifiée. Enfin, un décalage de carte est renvoyé. Ce décalage de carte indique un couplet qui peut être converti en une partie standard de document à données structurées.
PCT/US2002/000719 2001-01-23 2002-01-10 Procede permettant d'effectuer la recherche d'un modele objet de document numerique WO2002059726A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2002241843A AU2002241843A1 (en) 2001-01-23 2002-01-10 Method of performing a search of a numerical document object model

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/768,101 2001-01-23
US09/768,101 US6947932B2 (en) 2001-01-23 2001-01-23 Method of performing a search of a numerical document object model

Publications (2)

Publication Number Publication Date
WO2002059726A2 true WO2002059726A2 (fr) 2002-08-01
WO2002059726A3 WO2002059726A3 (fr) 2003-02-27

Family

ID=25081516

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2002/000719 WO2002059726A2 (fr) 2001-01-23 2002-01-10 Procede permettant d'effectuer la recherche d'un modele objet de document numerique

Country Status (3)

Country Link
US (1) US6947932B2 (fr)
AU (1) AU2002241843A1 (fr)
WO (1) WO2002059726A2 (fr)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4215425B2 (ja) * 2001-11-21 2009-01-28 日本電気株式会社 文章管理システム、その管理方法及びそのプログラム
US7133857B1 (en) * 2002-10-15 2006-11-07 Ximpleware, Inc. Processing structured data
US7761459B1 (en) 2002-10-15 2010-07-20 Ximpleware, Inc. Processing structured data
JP3982454B2 (ja) * 2003-05-27 2007-09-26 ソニー株式会社 携帯型電子機器、ウェブページ処理方法およびプログラム
US7694284B2 (en) * 2004-11-30 2010-04-06 International Business Machines Corporation Shareable, bidirectional mechanism for conversion between object model and XML
US7792811B2 (en) * 2005-02-16 2010-09-07 Transaxtions Llc Intelligent search with guiding info
CN102915239A (zh) * 2012-09-06 2013-02-06 佳都新太科技股份有限公司 一种基于标签的Jsp表单只读页面代码生成方法
JP7343311B2 (ja) * 2019-06-11 2023-09-12 ファナック株式会社 文書検索装置及び文書検索方法
CN113177223B (zh) * 2021-01-29 2024-06-28 张斌 一种基于数据属性动态因子实现的高安全性的数据可逆脱敏方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5426779A (en) * 1991-09-13 1995-06-20 Salient Software, Inc. Method and apparatus for locating longest prior target string matching current string in buffer
US5440738A (en) * 1991-05-16 1995-08-08 Tally Systems Corporation Method and apparatus for digital data processor file configuration detection
US5542086A (en) * 1993-07-06 1996-07-30 Novell, Inc. Document type metamorphosis in an object-oriented operating system having a graphical user interface

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5440738A (en) * 1991-05-16 1995-08-08 Tally Systems Corporation Method and apparatus for digital data processor file configuration detection
US5426779A (en) * 1991-09-13 1995-06-20 Salient Software, Inc. Method and apparatus for locating longest prior target string matching current string in buffer
US5542086A (en) * 1993-07-06 1996-07-30 Novell, Inc. Document type metamorphosis in an object-oriented operating system having a graphical user interface

Also Published As

Publication number Publication date
US6947932B2 (en) 2005-09-20
US20020099792A1 (en) 2002-07-25
WO2002059726A3 (fr) 2003-02-27
AU2002241843A1 (en) 2002-08-06

Similar Documents

Publication Publication Date Title
US7181680B2 (en) Method and mechanism for processing queries for XML documents using an index
US6782380B1 (en) Method and system for indexing and searching contents of extensible mark-up language (XML) documents
AU713572B2 (en) System and method for portable document indexing using N-gram word decomposition
US6263121B1 (en) Archival and retrieval of similar documents
US6516312B1 (en) System and method for dynamically associating keywords with domain-specific search engine queries
US6094649A (en) Keyword searches of structured databases
US7412444B2 (en) Efficient indexing of hierarchical relational database records
US6968338B1 (en) Extensible database framework for management of unstructured and semi-structured documents
US6697798B2 (en) Retrieval system of secondary data added documents in database, and program
US20100094835A1 (en) Automatic query concepts identification and drifting for web search
JP2007122732A (ja) ウェブドキュメントの集合において効率的に日付を検索する方法、コンピュータプログラム、およびサービス方法（ウェブドキュメントの集合において効率的に日付を検索するシステムおよび方法）
EP1552427A1 (fr) Indexation de demande a structure parents-enfants pour base de donnees xml
WO2007143666A2 (fr) procÉdÉ et systÈme d'interrogation d'ÉlÉment
US7457812B2 (en) System and method for managing structured document
EP1312039B1 (fr) Systeme et procede de preparation et de recherche automatiques de documents lus par balayage
JP2003519844A (ja) スタイルシートに基づいて構造化されたドキュメントのインデックスを作成する方法および装置
US20030023584A1 (en) Universal information base system
US7792866B2 (en) Method and system for querying structured documents stored in their native format in a database
US6947932B2 (en) Method of performing a search of a numerical document object model
US6792428B2 (en) Method of storing and flattening a structured data document
US20020099712A1 (en) Method of operating an extensible markup language database
US20050187964A1 (en) Method and apparatus for retrieving natural language text
US7089382B2 (en) Method of operating a hierarchical data document system having a duplicate tree structure
US20020099745A1 (en) Method and system for storing a flattened structured data document
US20030084027A1 (en) Control method for an extensible markup language file

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
AK Designated states

Kind code of ref document: A3

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP