Gail Mitchell

GTE Laboratories Incorporated

Waltham, MA 02454

gmitchell@gte.com

With increasing familiarity and use of the web at all levels of an organization, an intranet with web technology is becoming the mode of choice in business for delivering and presenting information. For example, the web is increasingly being used in business as an infrastructure for report distribution. In this context, a report is a document representing the extraction, manipulation and explanation of some business data. For example, the report used for illustration in this paper is the bill for a residential telephone customer.

A report might be delivered to a reader as a pointer in an email message, or might be selected by a reader from a list displayed in a web page (perhaps as pull-down menus), by filling out a form presented by a desktop application, by initiating a search, etc. In any case, web delivery of a report means that the content of the report may be assembled according to a predefined schedule (and stored in a web page), assembled at the time of request (and presented as a web document), or assembled in some combination of these time frames. XML and related technologies need capabilities for producing and presenting such dynamic report documents, and must also be able to model and query these documents.

This note explores some of the assembly and presentation characteristics of a business report that need to be addressed by web technologies. Although we do not propose any solutions at this point, we suggest some sample queries and issues to be considered when designing a query model and language for the web.

As a simple example of a report, consider a bill for a residential telephone customer. This report will have a variable number of sections and pages, depending on the number of calls made, special services billed, variety of long distance carriers, etc. The content of a section will depend in part on the style determined by the application producing the report, and partly on the data that needs to be displayed to the reader. For example, the style determined for presenting ‘Calling Services’ may include subsections for ‘Directly Dialed’ and ‘Operator Assisted’ calls, but a section will not appear in the report unless there are applicable calls to report. 

Much of the report consists of boilerplate, i.e., section headings (e.g., ‘Account Summary’, ‘Itemized Calls’), data descriptors (e.g., ‘Total Amount Due’, ‘Previous Balance’), column headings (e.g., ‘date’, ‘time’, ‘place called’, etc.), and other general information (e.g., the phone company logo, the title ‘Important Consumer Information’ and the succeeding explanatory text). The inclusion of some of this text may be standard for all reports (e.g., all have ‘Basic Local Services’ and ‘Total’s) or may depend on the data being reported (e.g., the time frame of the report, subscribed calling services, long distance carrier(s) used, whether the account is overdue). The data being reported will be extracted from one or more databases (or other sources) of information about customers, accounts, usage, line characteristics, long distance carriers, etc.

A basic issue that needs to be addressed by web technology is how to model such a document for presentation on the web. Most importantly, the model must be able to capture the mix of standard text and database data.

When a business document is presented on the web, a reader will (hopefully) not be aware of how the web document was constructed or from where the displayed data was obtained. Indeed, a reader will tend to view the contents of the document as data that ‘sits’ on the web and can be searched or queried. For example,

• A customer may ask to see the balance due on the current bill, or may ask to see the total amount paid in 1998. If we assume that a web document consists of a bill per month, the latter query will involve compiling ‘payments received’ data from many bills.
• An account representative may ask to see, for a given customer, all bills within the past two years that have charges from more than two long distance carriers. Such a query involves not only collecting bill documents, but can involve the structure of each document (i.e., how many long distance sections).
• A customer may ask to see all calls made to California in the past 3 months. Again, this involves compiling bills, but can also involve accessing a database of information describing what area codes need to be searched to give ‘California’.
• An account manager may ask to see a list of accounts with payments due. This query could involve matching (joining) a list of the manager’s accounts with the collection of current bills for each account.

These are only a few of the queries that could be asked of web documents, but they illustrate some of the situations that can arise in querying business reports. A query language must support the ability to pose such queries on business reports, both individually and collectively, regardless of how the document is constructed or stored (e.g., whether it is stored as a web page or compiled from data sources at the time of the query).

In addition, an application designer may want to take advantage of the web presentation to provide special query capabilities to the reader. For example, most phone bills have one or more places where 1-800 numbers are given for the customer to obtain additional information or ask questions. When the bill is presented on paper, these numbers are printed as boilerplate text in the relevant locations. However, when a bill is presented on the web, some of the information numbers could be replaced with links to pages providing the requested information. For example, payment information service could be obtained by displaying a form for requesting the information and constructing a query from the form data; selecting the ‘Carrier Line Charge’ report heading could display a page explaining the meaning of that term; a ‘Questions?’ button on a billing page for a long distance carrier could return a specific number for the customer to call based on the customer location, billing status, average charges, etc. (Perhaps it would go to the home page of the carrier’s customer service site.)

In these cases the sources for answering the query are not necessarily the web documents perceived by the reader, but are additional data sources accessed in preparing those documents. Access to these sources is embedded in the web document (perhaps as a query) and the data is manifested when the reader requests the information. This mode of data access is reminiscent of database views.

A query model and language for web documents must 1) be able to contribute to the production as well as the presentation of business reports, and 2) provide the ability to access and search these reports as web documents. Some of the issues that should be researched in designing such a model and language include:

• What are the possible sources for a query? How is a collection of web documents (e.g., current bills for representative X’s accounts) specified in a query?
• How is a business report document, as described here, related to a database view? In relational database languages, a query can specify a view of the database (both content and presentation) that can itself be queried as another database. A view can be virtual (in which case it focuses a query expression to the appropriate subset of data) or might be materialized as a snapshot of the database (for more efficient access, for example). Can the language used for querying web documents also be used within a web document for specifying access to other data sources and documents (i.e., a view)?
• What techniques will be useful for query optimization, and what needs to be built into a query language to take advantage of these techniques? For example, when looking for accounts with payments due, billing documents could be manifested and matched to customers, then payment status checked. However, it might be more efficient to first execute the operation computing payment status for each document and only manifest the remainder of the document if a payment is overdue.
• How will a query language access the form or structure of a business document? For example, how would the customer bill document be modeled, and what language constructs would be used to pose the query about bills with multiple long distance sections?
• On the other hand, will there be constructs in the query language to assist in production of web documents? For example, can a method be invoked to compute a summary? Database products often provide facilities for specifying the presentation of a query result. How can such a facility be integrated with web presentation functionality?
• Will object methods be useful in a model of web documents? For example, access to a source outside a document (such as a database, or another web page) can be modeled as a method whose execution returns the desired data. Similarly, a field in a report may be the result of a computation performed as a function execution. Work in object-oriented databases has investigated language constructs and query optimization for methods. How would this work apply to web documents?

The author would like to thank Sandy Heiler and Wang-Chien Lee (GTE Laboratories) and Stan Zdonik (Brown University) for discussions leading to the submission of this position paper.