A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office file or records, but otherwise reserves all copyright rights whatsoever.
1. Technical Field
The invention relates generally to the Internet communication technology. More particularly, the invention relates to a system and method for delivering and rendering scalable Web pages.
2. Background of the Invention
Authors of World Wide Web (WWW) documents all share a common and frustrating problem: the viewers of their documents have highly diverse viewing environments—especially with regard to the physical dimensions of the window a document is displayed in. This is problematic, especially if authors desire to produce documents with specific layout requirements. Hypertext Markup Language (HTML), the document format for WWW, provides very little in the way of scalable page elements. Many elements, text in particular, are fixed at specific sizes. When viewed on browsers with a large display resolution, text appears quite small when compared to displays with low resolution. Furthermore, even those elements that support some form of scaling are difficult to control because of the rudimentary manner in which the scaling support is provided. All this makes development of a consistent layout for WWW documents rather difficult.
One way for a document author to combat this problem is through the use of dynamic scripting languages such as JavaScript. These languages provide a way to detect information about a viewer's environment and modify the document accordingly. Unfortunately, the native document object code (DOM) provided by these languages is rather problematic. In the case of Netscape Navigator 4, not all of the page elements are accessible. Many elements are “write-only” or “read-only”, making it impossible to use the native structure as a reliable place to store document information.
Conversely, Internet Explorer (4 & 5) has a DOM that can be, at times, overly complex, making it difficult to constrain the degree to which a document should be modified.
Adding to the WWW author's problem is the fact that the DOMs used by Netscape Navigator and Internet Explorer are dramatically different in nature. Supporting both browsers requires the development of different scripts that can interact with the individual DOMs.
What is desired is to develop a browser independent document data structure which enable page authors to freely access and modify all relevant aspects of the document without having to worry about limitations of the browser DOMs.
The invention provides a system and process for displaying and redisplaying an HTML document that conforms to the limitations of a viewer's browser. The system comprises a browser, a script, and a document object model (DOM).
The script comprises a document data structure and an interpretation code. In the preferred embodiment of this invention, the document data structure is a slide presentation data structure designed for the system. The DOM is a document model representing a Web page's elements, such as text, images, URL links, etc.
Using this system, instead of creating an HTML document, a Web author creates his document that consists of the script. This script, when executed, creates a document data structure that describes the essential information in the document. The interpretation code interprets the data structure in a fashion that allows it to manipulate the DOM for the purpose of rendering the document in the browser.
By having the Web server provide the viewer's browser with a document data structure, instead of an HTML rendition of the document, the HTML for the document can be generated at a time when the browser information needed to create a properly sized document is available, thus allowing all features of the document to be sized accordingly. Furthermore, the data structure can be modified and the corresponding HTML can be subsequently regenerated in response to user events so that after initially being created, the document can be updated to reflect changes to the viewer's browser. For example, if the viewer resizes the browser, the page elements can be automatically resized.
By creating a browser independent data structure, the page author can freely access and modify all relevant aspects of the document without having to worry about limitations of browser DOMs. This browser independence also allows the author to develop a single script for interpreting the structure, rather than the two or more required for interpreting the different browser DOMs.
Referring to
The browser 110 may be any kind of Web browser that supports a scripting language with some means of modifying the contents of displayed web pages (also known as the browser Document Object Model).
The DHTML DOM 120 is a document model representing a Web page's elements, such as text, images, URL links, and the like.
The script 130 comprises a document data structure 140 and an interpretation code 150. The script is some combination of inline script (script included in the source HTML of a web page document) and script files referenced by the web page document. In the preferred embodiment of this invention, the document data structure 140 is a slide presentation data structure designed for this system. The hierarchical structure of said document data structure 140 is illustrated in
Using this system, instead of creating an HTML document, a Web author creates his document that consists of the script 130. This script, when executed, creates a document data structure 140 that describes the essential information in the document. The interpretation code 150 interprets the document data structure 140 in a fashion that allows it to manipulate the DHTML DOM 120 for the purpose of rendering the document in the browser.
The process to create a document data structure comprises the steps of:
Once the document data structure has been created, it can optionally perform any necessary data validation. This step, while not required, is frequently desirable to further format, validate, or optimize the data structure provided by the web server.
The Step 5 of the above process comprises the sub-steps of:
When the slide elements are text entities, the sub-step (e) of the above process comprises of the sub-sub-steps:
When said slide elements are image entities, the sub-step (e) comprises the sub-sub-steps:
When said slide elements are outline entities, the sub-step (e) comprises the sub-sub-steps:
The sub-step (g) of the above process comprises sub-sub-steps of:
In the sub-step (g), when slide elements are text entities, the sub-sub-step (dc) comprises of the sub-sub-sub-steps:
In the sub-step (g), when slide elements are image entities, the sub-sub-step (dc) comprises of the sub-sub-sub-steps:
In the sub-step (g), when slide elements are outline entities, the sub-sub-step (dc) comprises of the sub-sub-sub-steps:
The process to interpret the document data structure comprises the steps of:
The Step 3 of the above process comprises the sub-steps of:
When the slide elements are text entities, the sub-step (e) of the above process comprises of the sub-sub-steps:
When said slide elements are image entities, the sub-step (e) comprises the sub-sub-steps:
When said slide elements are outline entities, the sub-step (e) comprises the sub-sub-steps:
The Step 4 of the above process comprises the sub-steps of:
When slide elements are text entities, the sub-step (dc) under Step 4 comprises of the sub-sub-steps:
When slide elements are image entities, the sub-step (dc) under Step 4 comprises of the sub-sub-steps:
When slide elements are outline entities, the sub-step (dc) under Step 4 comprises of the sub-sub-steps:
By having the Web server provide the viewer's browser with a document data structure—a data structure that describes a document, instead of an HTML rendition of the document, the HTML for the document can be generated at a time when the browser information needed to create a properly sized document is available, thus allowing all features of the document to be sized accordingly. Furthermore, the data structure can be modified (and the corresponding HTML subsequently regenerated) in response to user events so that after initially being created, the document can be updated to reflect changes to the viewer's browser. For example, if the viewer resizes the browser, the page elements can be automatically resized.
Therefore, by creating a browser independent data structure, the page author can freely access and modify all relevant aspects of the document without having to worry about limitations of browser DOMs. This browser independence also allows the author to develop a single script for interpreting the structure, rather than the two (or more) required for interpreting the different browser DOMs.
A side benefit of this is that author-defined data structure can be optimized to include only the most essential information. This makes them much smaller than the equivalent HTML, which may help transmission times, especially over low bandwidth communication lines.
The document data structure and the interpretation code may be contained in a single file. This makes transport and portability easier, but requires the interpretation code be sent with each document.
The distinction between the document data structure and the interpretation code is essentially one of state vs. behavior. The document data represents the state needed to display a document, with little or no associated behavior.
The interpretation code provides the behavior needed for understanding a document data structure and creating an HTML representation of it. The interpretation code may be separated out from the document data structure code. This is expected to be the more attractive solution since it allows browsers to cache the interpretation code for later use on another, similar document.
SXSlide 210 is an object representing a single slide in a presentation. It contains any number of SXContentEntities 220 which are at the third layer.
SXContentEntity 220 is an abstract representation for one of a number of different types of slide elements. These types include: SXText 230, SXOutline 240 and SXImage 250.
The SXOutline 240 may, in turn, contain other sub-outlines 260.
Each of these entities in the presentation data structure has a variety of properties associated with it, which are described in the following tables.
This system supports a limited token replacement functionality. Table 1 contains (1) the recognized tokens, (2) the scope in which replacement occurs, and (3) the value with which they are replaced.
Additional tokens should use the ‘% TokenName %’ notation.
Token replacement is done using an exact string match method—only text that exactly matches the token, including the surrounding ‘%’ characters will be replaced. However, there is currently no way to escape the ‘%’ character so, for example, there is no way to have the string ‘% SlideNumber %’ appear in a SlideNumber element.
Table 2 through Table 8 list a type for the different properties. This type describes the semantic type of the object, not necessarily the data type, e.g. the zindex property, which is listed as being of type “integer”, is contained in a string data type. The type fields are listed in Table 2.
In this system a SXImage entity that has the name “Background” is treated specially. This content entity describes the background of a slide and is treated in the following ways:
Table 9 is a fragment of JavaScript illustrating what a document data structure looks like. In this sample, the document is a slide from a presentation document. Table 10 is a JavaScript that interprets the data structure for the slide. Table 11 is a JavaScript that interprets the data structure for an outline. Table 12 is the Java source code used by the web server to convert an arbitrary hashmap (as retrieved from a database) into a JavaScript data structure in the viewer's browser.
It is assumed that the content of a browser's web page is HTML. However, this needs not be true since more advanced browsers are capable of displaying other formats, most noteably, eXtensible Markup Language (XML). Therefore, the process described herein also fits other browser document formats and thus the HTML format is actually not a requirement for the process.
Although the invention is described herein with reference to the preferred embodiment, one skilled in the art will readily appreciate that other applications may be substituted for those set forth herein without departing from the spirit and scope of the invention.
Accordingly, the invention should only be limited by the Claims included below.
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/US01/03128 | 1/31/2001 | WO | 00 | 8/23/2003 |
Publishing Document | Publishing Date | Country | Kind |
---|---|---|---|
WO01/57718 | 8/9/2001 | WO | A |
Number | Name | Date | Kind |
---|---|---|---|
5751283 | Smith | May 1998 | A |
5781190 | Gorbet et al. | Jul 1998 | A |
6008807 | Bretschneider et al. | Dec 1999 | A |
6012083 | Savitzky et al. | Jan 2000 | A |
6243700 | Zellweger | Jun 2001 | B1 |
6456305 | Qureshi et al. | Sep 2002 | B1 |
6515656 | Wittenburg et al. | Feb 2003 | B1 |
6718515 | Conner et al. | Apr 2004 | B1 |
6748569 | Brooke et al. | Jun 2004 | B1 |
7047033 | Wyler | May 2006 | B2 |
20030208473 | Lennon | Nov 2003 | A1 |
20050132286 | Rohrabaugh et al. | Jun 2005 | A1 |
Number | Date | Country | |
---|---|---|---|
20040177327 A1 | Sep 2004 | US |