WO1996008780A1 - Data retrieval system - Google Patents

Data retrieval system Download PDF

Info

Publication number
WO1996008780A1
WO1996008780A1 PCT/GB1995/002177 GB9502177W WO9608780A1 WO 1996008780 A1 WO1996008780 A1 WO 1996008780A1 GB 9502177 W GB9502177 W GB 9502177W WO 9608780 A1 WO9608780 A1 WO 9608780A1
Authority
WO
Grant status
Application
Patent type
Prior art keywords
access
data
modules
document
database
Prior art date
Application number
PCT/GB1995/002177
Other languages
French (fr)
Inventor
Stephen Mckearney
Original Assignee
British Telecommunications Public Limited Company
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

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00Digital computing or data processing equipment or methods, specially adapted for specific functions
    • G06F17/30Information retrieval; Database structures therefor ; File system structures therefor
    • G06F17/30011Document retrieval systems
    • G06F17/30014Hypermedia

Abstract

A documented database provides a simple hypertext interface, to local and centralised data held in relational databases. A database consists of a set of modules (5, 6, 7, 8) that each contain a data part (25, 26, 27, 28) which is a small closely coupled set of data, and a text part (15, 16, 17, 18), which is a short textual description of the data part. Documents (14) are constructed, or 'instantiated', from templates by retrieving selected modules (5, 6, 7, 8) stored in the database. The text parts (15, etc.) of each retrieved module (5, etc.) are compiled into a composite textual description of the selected data.

Description

DATA RETRIEVAL SYSTEM

This invention relates to data retrieval systems. Currently, conventional relational database systems provide access to data via general-purpose query languages, for example, SQL as described in van der Lans R F , Introduction to SQL, Addison-Wesley, 1993; and QUEL, as described in Stonebraker M (ed), The INGRES Papers, Addison-Wesley, 1986. The principal advantage of these languages is that they provide applications with a standard method of accessing multiple database systems.

Increasingly, commercial tools are being used to isolate the user from the complexities of these query languages, for example PowerPlay 3.0, produced by COGNOS Incorporated. However, although these tools provide sophisticated graphical interfaces, they do not inherently aid the user's understanding of the database structure. This understanding can only come from appreciating the specific process that led to the current database design.

Typically, a database consists of entities and relationships which describe the structure of the data, as described in Batini C, Ceri S and Navathe S B. Conceptual Design - An Entity-Relationship Approach, The Benjamin/ Cummings Publishing Company, Inc, 1992.

A database is a store of constantly changing data but the database structure has many of the properties of program source code. In particular, the structure is described using a database language called the data definition language. However, unlike a program's source code, there can be many different 'views' of the database. The databases are normally accessed through a network, so that they are accessible to a number of users.

Hypertext is a method of relating many unique documents according to their content. It is described in detail in Nielsen J, Hypertext and Hypermedia, Academic Press, 1990. A user reads hypertext documents by following links that point to related documents. In this way hypertext provides a simple method of relating information from many sources. Relational databases are large stores of data held in collections of tables, their characteristics are discussed in Elmasri R, Navathe S B, Fundamentals of Database Systems, The Benjamin/Cummings

SUBSTITUTE LHEET (RULE 26) Publishing Company Inc, 1989. Typically each row in a table represents an object in the world and each column within a row describes some property of that object. A database query retrieves information from these tables.

Database and hypertext technologies complement each other. Hypertext systems tend to be relatively static; large databases tend to change frequently. Hypertext systems store information as relatively unstructured unique documents; whilst databases store many similarly structured facts. The table below shows a comparison of hypertext systems and database systems.

Characteristics Hypertext Database

Data Type Static Dynamic

Variety Different Similar

I Information Held Documents Facts

I Model Unstructured Structured

Size Small Large

Table 1 : Comparison of Hypertext & Databases

Data storage in a hypertext systems is normally done using network databases, as described for example by Leggett J J and Schnase J L in "Dexter with Open Eyes", Communications of the ACM, Vol 37, No 2, February 1 994. However, the data is stored and retrieved in a conventional manner, which limits the ways in which the data can be presented. In a contribution entitled "Networked Biomedical Image Hyperbase" presented to the WWW '94 Conference workshop, 'Teaching and Learning with the WEB' at the First International Conference on the World-Wide Web, (CERN, Geneva, Switzerland, May 1994), Duval et al describe an image database, based on the WWW (World-Wide Web) system, that uses the "forms" facility of Hypertext Markup Language (HTML) to create a screen format which the user can use to input or extract information, thereby providing an interface to existing database systems. (The World Wide Web itself is described by Berners-Lee T J, Cailiau R, Groff J-F, and Pollermann B, in a paper "World-Wide Web: The Information Universe", published in "Electronic Networking: Research, Applications and Policy", Vol 2, No 1 ,pp 52-58 Spring 1992, Meckler Publishing, Westport, CT, USA).. In a paper entitled "Using Events as Support for Data Sharing in Collaborative Work", in the Proceedings of the International Workshop on CSCW pages 162 to 177, (Gorling K and Sattler C editors Berlin, April 1991 ) Wiil has developed a hypertext database called HyperBase, which uses a simple data model to store information based upon nodes and links between nodes. The system is intended to support collaborative working and the paper investigates the issues involved in sharing information among many users. however, the data itself is still stored and retrieved conventionally, leading to the constraints discussed above. According to a first aspect, the present invention comprises a data storage system for use in generating a document, the system comprising data access means and a data storage means wherein the data storage means has a structure having a first level containing instances of data and a second level containing access modules allocated to respective areas of the first level, each access module containing at least one data access instruction, the data access means having access to the access modules, and the access modules being triggerable by the data access instructions contained therein to access one or more selected instances of data from the first level, so as to generate a document from the relevant one or more selected instances of data. According to a second aspect, the invention comprises a method for generating documents from stored data, the method comprising the steps of defining a data storage structure, having instances of data and a set of access modules allocated to respective instances of data or groups of instances of data, and generating the documents by triggering a selected access module, .retrieving the respective data instances, and compiling the retrieved data into a document.

According to a third aspect, the invention comprises a database access tool for use in generating a document from data instances stored in a data storage structure, comprising one or more access modules each defining an associated area of the data storage structure, the access modules being triggerable to access one or more selected instances of data from their respective associated area of the data storage structure, so as to generate a document from the selected data instances. By defining the database structure in terms of the hypertext model the data may be retrieved in many different ways, tailored to the requirements of the individual user, and incorporated into hypertext documents to form a seamless whole. In particular, the data will be retrieved afresh every time the document is accessed, so that the data presented in the document is automatically updated.

The designer can define the structure of the database according to the nature of the data to be stored, and to store this definition within the database, such that a user can retrieve it. Each access module is defined by a collection of entities and relationships which operate to allow specified data to be retrieved in a specified format. The same set of data may be retrievable in different formats, or in combination with other data sets, by using different access modules. The procedure allows the application of so-called 'literate programming' methods (to be described in detail below) to data retrieval.

In this invention, the relational database structure is utilised by means of access modules which are means for accessing specified instances or groups of instances of data. In a preferred arrangement, the access modules include a corresponding narrative description about the entities they access, and their relationships to each other. Each access module within the database forms a unit of information that a user of the database will access. Preferably, the structure of the data storage means has a third level containing template modules allocated to respective areas of the second level and each containing at least one access module access instruction, the data access means having access to the template modules and the template modules being triggerable by the access module access instructions contained therein to access one or more access modules from the second level.

The access modules and/or template modules may contain label information, the data access means being triggerable to generate a document from the label information and selected data.

The label information associated with the template modules may define label compilation instructions for compiling the label information of the associated access modules into a composite document.

Literate programming is a method of writing documented computer programs [Knuth D E , Literate Programming, Centre for the Study of Language and Information, 1992]. A literate program is read in much the same way as a book or a paper. Tools convert the documented code into a compilable form. Empirical evidence indicates that literate programs are more robust, more portable and easier to maintain than other known programs, as discussed by Knuth D E, in "The Stanford GraphBase: A Platform for Combinatorial Computing", ACM Press, 1994.

A literate program is composed of a set of modules each consisting of a short narrative description and a short piece of code. The final program is built from these modules. Each module has a name that may be referenced from other modules of the program. This ability to reference other modules allows the order of the modules to be determined by the programmer rather than the compiler. A good literate program is written in a style that is easy to read and understand. A module that processes and prints data in a loop might look like:

"8. This module processes the values of a loop and then prints the results on the screen. The loop uses the variable which ranges over the values 0 to 9. < process data > = for (i =0; i < 10; i + + )

{

< process single value > < print result >

}

This example shows a module called 'process data'. The module consists of two parts: (i) a narrative description describing the purpose of the module and explaining the algorithm and variables used, and (ii) the program code section that implements the algorithm. This code makes reference to two further modules, 'process single value' and 'print result'. When this module is compiled these references are replaced by their underlying code, for example: for(i = 0; i < 10; i + + ) ( n = i*2; print("%d\n",n); The present invention applies these principles to data retrieval. It is important to note, however, that in a conventional 'literate program' the narrative description and the operating instructions derived from the code are independent, being for the use of the human reader and the computer respectively. In the present invention the narrative description and the data generated from the code both become integral parts of the resulting document.

An embodiment of the invention will now be described by way of example, with reference to the following Figures, in which: Figure 1 shows diagrammatically the organisational layout of a database according to the invention;

Figure 2 shows a high-level representation of the database structure;

Figure 3 shows an access module of the database retrieval system;

Figure 4 shows a typical output produced when the access module of Figure 3 is executed;

Figure 5 shows a template module of the database retrieval system;

Figure 6 shows a typical output produced when the template module of Figure 5 is executed;

Figure 7 is a flow chart showing the processes taking place within the system;

Figure 8 illustrates the generation of a document using the processes of Figure 7;

Figure 9 shows a typical instruction for operating the system.

The database has two levels (see Figure 1 ):

* The database level (1 ) is the physical level, and is the traditional database structure based on the entity-relationship model or similar structure * The module level (2) is a collection of database modules (access modules and/or template modules as described below), describing specified regions of the database. Each module consists of a narrative description of a region and the set of entities and relationships within it.

SUBSTITUTE SHEET (RULE 20 The document (3) is an external level that is viewed by the user and consists of sets of modules, or documents.

Figure 2 shows a high level representation of this structure. In Figure 2 the database 4 contains a number of access modules 5, 6, 7, and template modules 8. Each access module 5, 6, 7 consists of a narrative statement and a set of entities and relationships. This structure is implemented as a text component 15, 16, 17 and a database component 25, 26, 27. An access module has two states, referred to below as "uninstantiated" and "instantiated". In the uninstantiated state (Figure 3) the access module includes an instruction 35 to display the data in a specified region of the database. In the instantiated state (Figure 4) the data itself (25) is displayed. The uninstantiated form is invariant, but the instantiated form will depend on the current content of the database 4. The designer constructs an uninstantiated access module for different regions of the database. An access module is instantiated by executing queries defined within the access module. For example, as shown in Figure 3, an access module "clients" 5 might be constructed to describe the clients of a company. This access module includes a text component 15 which describes that part of the database which stores information about clients, and a database component 35 which comprises an instruction to retrieve the relevant data 25. This access module is instantiated by executing the query defined in the database component 35 with the result shown in Figure 4, showing text 15 and data 25.

Template module 8 can be used to produce documents 14 by accessing several access modules 5,6, in the same way that the access modules themselves access their associated data. An uninstantiated document, or template, specifies a set of access modules 5, 6 that should be used to produce an instantiated document. For example, Figure 5 shows template module 8 that describes clients and customers within the database by referencing two access modules, the "clients" access module 5 referred to above, and a "customers" access module 6 , and includes its own text 18. Figure 6 shows how this template module 8 might be instantiated. The resulting document 60 consists of the text 18 from the template module 8, the instantiated 'clients' access module 5 described above, consisting of text 15 and

SUBSTITUTE SHEEF (RULE 26) data 25, and the instantiated 'customer' access module 6, consisting of text 16 and data 26.

There may be a hierarchy of template modules, with some (high level) template modules accessing the relevant access modules indirectly, through other (lower level) template modules.

A prototype system is described below which is based on the WWW client/server environment and uses the HyperText Markup Language (HTML) to specify database access modules and document templates. The system has certain desirable properties: a) Database queries within an HTML document do not interfere with existing HTML commands, b) An HTML database document is consistent with standard HTML documents, c) The results of a database query can be formatted using HTML, d) The Common Gateway lnterface(CGI) [The Common Gateway

Interface, http://hoohoo.ncsa. uiuc.edu/cgi/] standard is used to integrate with existing WWW servers, e) The document is dynamically generated and thus reflects the current state of the database, f) HTML documents can be stored in the database, and g) The system works with commercial database systems.

The new version of HTML used in this embodiment has three new commands: * A database query command which retrieves data from the database,

* A template parameter command which provides parameter-passing in documents, and

* A module reference command which includes database modules in a document.

This version of the HyperText Markup Language (HTML) was published in draft form on the Internet 13/1 /94 by Berners-Lee T and Connolly D, and the current form is accessible on http://www.w3.org/hypertext/WWW/MarkUp/html- spec/html-spec_toc.html.

As shown in Figure 7, there are three processes 41 , 42, 43 involved in conversion from an HTML source document (database document) 52 to a standard HTML document 53. Each process corresponds to one of the three new commands. The system can be implemented in C and Perl and can be based on a relational database such as Oracle .

Database Query Command (41 ) The syntax for a database query is:

<sql"SQL-Query" >

The system processes each document and passes all database queries to the appropriate database system to be executed. The resulting data is inserted into the document and recursively processed by the system. In this way the results of a query can include further database queries.

Figure 8 shows a source document 52, its corresponding HTML document 53 and the final displayed document 51. In this example, the document consists of a title and heading, 'Current Projects' 54 and a bullet point list 55 delimited by <ul> and < /ul > . The list of projects 55 is retrieved from the database by the SQL SELECT statement "select ' <li> ' ||project_title from projects" 56. This statement uses the string concatenation operator ( ||) to include the HTML bullet point ("List Item") command < li > , so that in the resulting document each item in the list is preceded by a "bullet point". The SQL SELECT statement also specifies the ordering of the selection made.

Template Parameters (42)

By itself, the query command is limited to retrieving a fixed set of data. To provide dynamic queries, which return different results depending on the user's requirements, it is necessary to adapt the definition of the query when the final document 51 is being constructed. That is, we would like to be able to parameteπse the query. The system has the ability to use the parameter passing mechanism of the Common Gateway Interface (CGI) documented at http://hoohoo.ncsa.uiuc. edu/cgi/. The Universal Resource Locator (URL) standard documented at http://info.cern.ch/hypertext/WWW/ Addressing.html, and supported by the WWW, allows parameters to be passed to a document, for example:

< a href = "http://site/db-bin/db-process/document.html?param1 + param2" > Document < /a >

The result of selecting this HTML document reference is that the program "db-process" in directory "db-bin" processes the document "document.html" using the parameters "paraml " and "param2". These parameters can be accessed within the HTML-SQL document using the template parameter command: < env n >

When processed by the system this command is expanded to the nth argument specified by the document URL. Given a parameter '01 /01 /94' the query:

< sql" select project_title from project where startdate = ' < env 1 > '" >

will expand to:

< sql"select project_title from project where startdate = '01 /01 /94'" >

Access module References (43)

In a documented database the database structure consists of one or more access modules which are composed of data and narrative descriptions. To build a document from these access modules an author makes one or more access module references which extract the appropriate access modules 5, 6, 7, 8 from the database 4. The system provides the following command:

< module module-name{param-n} > An access module reference is expanded into the corresponding text block and processed by the system in the same way as standard HTML-SQL documents. Database access modules are stored in a database relation, html docs, that consists of three columns, or attributes:

* title The unique name of the access module

* line A unique identifier for each line of the access module

html A line of text from the access module

Any access module in the database can be retrieved using a simple query.

For example, in Figure 9, a query 57 retrieves the access module PROJECTS. The query 57 retrieves the html attribute for all rows with title = 'PROJECTS' from the table html docs and sorts them by line. As the retrieved access module will be scanned for additional queries, this query allows all access modules and document templates to be stored in the database.

Three principal types of access module can be identified: a) Overview Descriptions These narratives present overviews of sections of the database and point to other access modules within the data.

These narratives may act as menu options for other descriptions, b) Entity/Relationship Class Descriptions These narratives essentially describe the structure of the data in the database. They describe design issues and decisions or indicate how particular aspects of the database structure may be queried, and c) Entity/Relationship Instance Descriptions These narratives describe specific examples of data within the database, for example, a particular project.

As a tool for accessing databases the documented database approach provides support for: (i) database browsing, where the objective is to explore the data by accessing detailed descriptions of the database structure and content; and

(ii) database reporting, where standard documents are retrieved which provide information on specific aspects of the database.

Claims

1 . A data storage system for use in generating a document, the system comprising data access means and a data storage means wherein the data storage means has a structure having a first level containing instances of data and a second level containing access modules allocated to respective areas of the first level, each access module containing at least one data access instruction, the data access means having access to the access modules, and the access modules being triggerable by the data access instructions contained therein to access one or more selected instances of data from the first level, so as to generate a document from the relevant one or more selected instances of data.
2. A system according to claim 1 , in which the access modules contain label information, the access modules being triggerable by the data access means to generate a document from the label information and the relevant one or more selected instances of data.
3. A system according to claim 1 or 2, wherein the structure of the data storage means has a third level containing template modules allocated to respective areas of the second level and each containing at least one access module access instruction, the data access means having access to the template modules and the template modules being triggerable by the access module access instructions contained therein to access one or more access modules from the second level.
4. A system according to claim 3, in which the template modules contain label information.
5. A system according to claim 2 or 4, in which the label information is text relating to the data accessed by the data access instructions of the respective access module or template module.
6. A system according to any preceding claim, wherein the data storage structure comprises means for amending the data stored therein.
7. A method for generating documents from stored data, the method comprising the steps of defining a data storage structure, having instances of data and a set of access modules allocated to respective instances of data or groups of instances of data, and generating the documents by triggering a selected access module, retrieving the respective data instances, and compiling the retrieved data into a document.
8. A method according to claim 7, wherein the step of defining the data storage structure comprises the steps of defining some members of the set of access modules as template modules associated with other access modules, and the step of generating a document comprises triggering a template module, selecting the access modules associated with the template module, retrieving the data instances associated with the selected access modules, and compiling the associated retrieved data imo a document.
9. A method according to claim 7 or 8, wherein the access modules have associated label information, and the label information is compiled with the retrieval data to form a document.
10. A method according to claim 9, when dependent on claim 8, comprising the additional step of defining label compilation instructions associated with the template modules for compiling the label information of the associated access modules into a composite document.
1 1. A method according to claim 9 or 10, in which the label information is text relating to the data accessed by the respective access module.
SUBSTITUTE SHEET (HULE 26)
1 2. A database access tool for use in generating a document from data instances stored in a data storage structure, the tool comprising one or more access modules each defining an associated area of the data storage structure, the access modules being triggerable to access one or more selected instances of data from their respective associated areas of the data storage structure, so as to generate a document from the selected data instances.
13. A database access tool according to claim 1 2, further comprising template modules for defining one or more access modules, the template modules being triggerable to trigger the associated access modules.
14. A database access tool according to claim 12 or 1 3, further comprising label generation means associated with each access module, the access modules being triggerable to generate a document from the selected data instances and labels generated by the label generation means.
1 5. A database access tool according to claim 14, when dependent on claim 1 3, in which the template modules have associated label generation means to compile a composite label from the label generation means associated with the associated access modules.
1 6. A database access tool according to claim 4 or 1 5, in which each label generation means generates text relating to the data accessed by the respective access module.
SUBSTITUTE SHEET (HULE 26}
PCT/GB1995/002177 1994-09-14 1995-09-14 Data retrieval system WO1996008780A1 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP94306720 1994-09-14
EP94306720.7 1994-09-14
GB9423039A GB9423039D0 (en) 1994-11-15 1994-11-15 Data retrieval system
GB9423039.8 1994-11-15

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
AU3480995A AU3480995A (en) 1994-09-14 1995-09-14 Data retrieval system

Publications (1)

Publication Number Publication Date
WO1996008780A1 true true WO1996008780A1 (en) 1996-03-21

Family

ID=26137287

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB1995/002177 WO1996008780A1 (en) 1994-09-14 1995-09-14 Data retrieval system

Country Status (1)

Country Link
WO (1) WO1996008780A1 (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998014896A1 (en) * 1996-09-30 1998-04-09 Sterling Software, Inc. Web server data/process integrator
EP0924628A2 (en) * 1997-12-22 1999-06-23 Hewlett-Packard Company Methods and system for using web browser to search large collections of documents
EP0974098A2 (en) * 1997-02-07 2000-01-26 General Internet, Inc. Collaborative internet data mining system
WO2000077663A2 (en) * 1999-06-14 2000-12-21 Lockheed Martin Corporation System and method for interactive electronic media extraction for web page generation

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
J. CELKO :: "SQL report writers don't always speak your language", SYSTEMS INTEGRATION, vol. 24, no. 1, NEWTON US, pages 19 *
J. GAUGER :: "Automatische Dokumentation von Automatisierungsprojekten", AUTOMATISIERUNGSTECHNISCHE PRAXIS - ATP, vol. 33, no. 9, MUNCHEN DE, pages 477 - 484 *
S. SHUM & C. COOK :: "AOPS : an abstraction-oriented programming system for literate programming", SOFTWARE ENGINEERING JOURNAL, vol. 8, no. 3, UK, pages 113 - 120 *
T. BERNERS-LEE & R. CAILLIAU :: "World-Wide Web", PROCEEDINGS OF THE INTERNATIONAL CONFERENCE ON COMPUTING IN HIGH ENERGY PHYSICS '92, 21 September 1992 (1992-09-21), ANNECY, FRANCE, pages 69 - 74 *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998014896A1 (en) * 1996-09-30 1998-04-09 Sterling Software, Inc. Web server data/process integrator
EP0974098A2 (en) * 1997-02-07 2000-01-26 General Internet, Inc. Collaborative internet data mining system
EP0924628A2 (en) * 1997-12-22 1999-06-23 Hewlett-Packard Company Methods and system for using web browser to search large collections of documents
EP0924628A3 (en) * 1997-12-22 2005-08-24 Hewlett-Packard Company, A Delaware Corporation Methods and system for using web browser to search large collections of documents
WO2000077663A2 (en) * 1999-06-14 2000-12-21 Lockheed Martin Corporation System and method for interactive electronic media extraction for web page generation
WO2000077663A3 (en) * 1999-06-14 2002-01-17 Lockheed Corp System and method for interactive electronic media extraction for web page generation

Similar Documents

Publication Publication Date Title
Marshall et al. Spatial hypertext: designing for change
Davies et al. Semantic Web technologies: trends and research in ontology-based systems
Baru et al. XML-based information mediation with MIX
US6456308B1 (en) Embedded web server
US5764973A (en) System for generating structured query language statements and integrating legacy systems
US5983267A (en) System for indexing and displaying requested data having heterogeneous content and representation
US6567812B1 (en) Management of query result complexity using weighted criteria for hierarchical data structuring
US5315709A (en) Method and apparatus for transforming objects in data models
Garg et al. A hypertext system to manage software life-cycle documents
US6763343B1 (en) Preventing duplication of the data in reference resource for XML page generation
US6279015B1 (en) Method and apparatus for providing a graphical user interface for creating and editing a mapping of a first structural description to a second structural description
US6233600B1 (en) Method and system for providing a networked collaborative work environment
US6487566B1 (en) Transforming documents using pattern matching and a replacement language
US6947945B1 (en) Using an XML query language to publish relational data as XML
US7233950B2 (en) Method and apparatus for facilitating use of hypertext links on the world wide web
US20020087571A1 (en) System and method for dynamic generation of structured documents
US20020007373A1 (en) System, method, and computer program product for knowledge management
US7257569B2 (en) System and method for determining community overlap
US6704723B1 (en) Method and system for providing business intelligence information over a computer network via extensible markup language
US20030020746A1 (en) System and method for dynamically generating a web page
US5752021A (en) Document database management apparatus capable of conversion between retrieval formulae for different schemata
US7015911B2 (en) Computer-implemented system and method for report generation
Garofalakis et al. XTRACT: a system for extracting document type descriptors from XML documents
US20030037076A1 (en) Method, computer program and system for style sheet generation
US6766330B1 (en) Universal output constructor for XML queries universal output constructor for XML queries

Legal Events

Date Code Title Description
AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): KE MW SD SZ UG AT BE CH DE DK ES FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN ML MR NE SN TD TG

AK Designated states

Kind code of ref document: A1

Designated state(s): AM AT AU BB BG BR BY CA CH CN CZ DE DK EE ES FI GB GE HU IS JP KE KG KP KR KZ LK LR LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK TJ TM TT UA UG US UZ VN

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
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 in:

Ref country code: CA