The present invention is directed to the field of electronic documents, and, more particularly, to the fields of electronic document generation and adaptation.
Displayed web pages contain various kinds of visual information, such as text, images, and links. In some cases, it is desirable to adapt visual information from another source (“included information”) for inclusion in a displayed web page. For example, it is sometimes desirable to adapt the contents of a first web page for inclusion in a second web page. This can be useful to present the contents of the second web page in the larger and more persistent context of the first web page.
Certain conventional techniques adapt included information from another source for inclusion in a displayed web page, in that they to adapt the contents of a first HTML web page for inclusion in a second HTML web page. As part of doing so, these conventional techniques transform links occurring in the second HTML web page such that, when these links are traversed, the linked-to information is also displayed in the context of the first HTML web page. These convention techniques also provide for the display of the second HTML web page within the first HTML web page.
These conventional techniques have significant limitations, however, that prevent them from successfully being applied to the more general problem of adapting included information from sources of a wider variety of types, for inclusion in web pages or a wider variety of types. In particular, these conventional techniques are unable to identify and transform links occurring in included information that is not an HTML document, such as included information that is an XML document. In order to enable products using these conventional techniques to identify and transform links occurring in documents of a new type, it would be necessary to develop and distribute a new version of such products.
These conventional techniques are also unable to discern between different types of links in the included document, and transform links of different types in different ways.
Additionally, these conventional techniques are unable to display certain constituent parts of included HTML documents that are not expressed in native HTML, such as XML data islands, which are commonly added to HTML documents by certain applications used to generate HTML documents.
In view of the disadvantages discussed above, a more universal and adaptable system for including information from another source in a displayed web page would have significant utility.
A software facility for electronic document publishing and rendering (“the facility”) is described. In particular, the facility prepares electronic content, such as electronic documents, for presentation using a web framework. The web framework can provide such features as: maintaining a consistent visual contexts through the display of a series of different documents from different sources, having different appearances, and/or of different types; tracking the user's browsing activities; providing user authorization services; and enforcing other rules relating to actions the user is able to perform, responses thereto, and the identity and form of displayed information. The display using the framework may be provided as part of a distributed application.
The facility divides the presentation of documents into two differentiable tasks: document publishing, in which a published document is adapted for display within a web framework, and document rendering, in which a rendered document (or other rendered content) is adapted for incorporation in a published document that will be displayed within a web framework. In some embodiments, rendering a document can include converting its type to the type of the published document in which it is incorporated.
In some embodiments, the facility performs document publishing using components that are separate from those used to perform document rendering. In some embodiments, these publishing and rendering components are further divided into versions designed for publishing or rendering documents of a particular type, such as HTML documents. The segregation of publishing and rendering functionality into per-document type components allows the facility to be straightforwardly augmented to process documents of new types.
In some embodiments, each such document type-specific publishing or rendering component is provided as an object class, such that an object of the appropriate class may be instantiated to publish or render a document of a particular type. In some embodiments, all of theses classes are defined as subclasses of abstract publishing and rendering classes, and instances of these classes are instantiated using an abstract class factory for the abstract class. This generally enables new subclasses for publishing or rendering new document types to be developed, distributed, and incorporated in the facility without recompiling or redistributing the facility itself.
The process of publishing or rendering a document often includes the subtask of processing links occurring in the document to support the proper operation of the framework and the enforcement of its rules. In some embodiments, the facility separates the processing of links in published and rendered documents from the larger processes of publishing and rendering those documents. This enables link processing steps, such as link identification, link mapping, and link substitution to be provided by one or more link processing components that are separate from the publishing and rendering components. This isolation of link processing functionality facilitates the reuse of the facility with multiple different frameworks, and with different applications imposing different rules.
In the ways described above, the facility provides powerful and adaptable tools for presenting information contained in electronic documents in conjunction with web frameworks.
Publishing as discussed herein means transforming an input stream into an output stream that is logically equivalent but functions within the application's framework. With web documents, this means that the links within the document must be transformed but the document itself remain visually identical when presented to the browser. The facility uses publishing façades to publish documents.
Publishing façades have the following abstract interface:
Applications of the publishing façade provide a publishing environment specified minimally as follows:
with a concrete instance of the URL Renderer Mediator class that supports the following interface:
The application of the publishing system creates the publishing façade based on the input stream's content type using an abstract factory. The application then initializes the façade with the property bag for the content type and a concrete URL rendering mediator that implements the link transformation logic that it wishes to enforce. Once this is done, the application may pass an input stream of the content type to the publish method in order to get an output stream that is compatible with its link publishing rules. The publish method may be invoke many times.
The concrete instance of the publishing facade uses the input property bag and built in content type handling logic to locate links in the three categories described below and asks the concrete URL Renderer Mediator to publish them. The identified links are passed to the mediator in a syntax that is relative to the current stream. The mediator is expected to return a rendered URL in relative format (possibly the same URL).
The implementation of the publishing façade abstracts
The design allows for efficient stream handling of the input file and does not require buffering of entire input document to generate the output document.
A sample application includes concrete publishing facades for
Rendering as discussed herein means generating an output stream suitable for display within the context of another web document. This is different than publishing because the output stream must be of the same content type as the document that it will be inserted into. In addition, the transformations required for the links may be different from those that would be used for publishing the same document.
A sample application includes a rendering engine for HTML. Separate engines may be implemented for inline rendering in content types such as WML and/or HDML. HTML rendering façades support the following abstract interface:
In addition to the property bag for the content type, applications of the HTML Rendering Façade pass in an abstract property bag containing details about the object to be rendered supporting (minimally) the following interface:
Since this interface is abstract, the actual work of retrieving the content can be deferred for cases where the content stream is not used in the rendering (for example, links to images).
The application also passes in a rendering environment specified as follows:
with a concrete instance of an URL Renderer Mediator, discussed above.
The application of the publishing system creates the HTML rendering façade based on the input stream's content type using an abstract factory. The application then initializes the façade with the property bag for the current content type, a property bag of information about the content, and a rendering environment including a concrete instance of the URL Renderer Mediator implementing its application-specific link rendering rules.
The application's URL Renderer works just as in the publishing façade. However, since more is known about the desired output markup type, the HTML Rendering Façade provides a HTML Link Context that the application may use to set additional properties on the link during calls to its URL Renderer methods. The link context is specified minimally as follows:
The application requests the HTML document components in order (HTML attributes, HEAD content, BODY attributes, BODY content). BODY content may be requested multiply with different list of XPath exclusions (tags not wanted in the body).
The concrete instance of the HTML Rendering Façade is responsible for formulating the HTML markup to be used while rendering the object and ensures that links are published via the URL Renderer.
A sample application includes HTML rendering facades for content types such as the following:
Because the publishing and rendering façades limit the knowledge about the internal state that the applications have, they can be implemented by aggregating modular link analysis and link substitution logic. This modular logic can be shared across both interfaces.
The modular link analysis and link substitution logic may be implemented, for example, by a link analysis façade specified as follows, together with a link substitution façade specified as shown below:
The link substitution façade is specified as follows:
A link mapping table contains a set of link mappings. The table allows efficient lookup of links matching given criteria.
Each link mapping has an original link and a mapped link.
The Link substitution façade uses the link mapping table to efficiently determine mappings required for identified links. If no mapping is found, the façade copies the link to the output stream without changing it.
In some embodiments, these facades may also form the basis of an import subsystem.
The behavior of links in web content depends on the context of the link. For example, in HTML documents, graphic links occur within the context of an IMG tag and result in the display of a graphic that appears in line to the HTML page.
The system classifies links as being simple, integral, or inclusive. Internally, the system also sub-classifies base links and script links.
Simple links are links that allow the user to traverse from one document to another separate document. An example of a simple link is a HTML HREF.
Integral links are links that cause the browser to pull the contents of the other document into the current document. An example of an integral link is a HTML IMG.
Inclusive links are links that cause the browser to treat the linked document as being part of the current document. Examples of inclusive links include XSL include links.
When returning links, the façade classes categorize them for the application this allows correct treatment of complex links in the web site. For example, an application of the HTML renderer may want to display simple links to other HTML documents using the same HTML renderering application while displaying other simple links in new browser windows. The treatment of the links is left to the application.
The publishing and rendering system hinges on the existence of concrete instances of the following content type abstract factory:
Concrete instances of this factory are instantiated using an abstract class factory provider based on a setting in the content type property bag using dynamic class instantiation.
Embodiments of the facility achieve configurability at two levels. The facility supports algorithm configurability and fine-grain setting configurability.
Algorithmic configurability is the ability to dynamically adapt portions of the overall algorithm to specific inputs. In the publishing and rendering system, algorithmic configurability is achieved at the content type level through the use of an abstract factory that constructs concrete facades with abstract interfaces to perform the following tasks:
The system selects the appropriate algorithm façade based on the content type of its input stream. Content types are mapped to input streams at an earlier stage using accepted web heuristics including the document's mime content type, extension, SGML document type, and XML namespaces. The mapping of the concrete instance of the abstract factory to the content type is achieved via setting configurability. The concrete factory is loaded using dynamic class loading. Thus, the system may be dynamically expanded to provide custom handling for other content types without requiring recompilation, linking, or re-distribution of any of the non-façade components.
Setting configurability is achieved by defining a database of open-ended string properties for each content type that the system handles. The string properties are modifiable and expandable at runtime. The set of properties defined depends on the requirements of the facades associated with the content type.
At a minimum, the property set generally includes the name of the concrete factory to use when instantiating facades for the content type. For markup languages, the property set includes XPath specifications for a link types found in the class of markup document. These settings are used to implement link categorization.
In order to more fully describe the facility, its operation in conjunction with an example is described. The example involves tracking subscriber readership of magazine articles for an online magazine company whose articles each consist of a HTML page containing text, links, and pictures.
On the magazine web site, both the full articles and the individual pictures can be reached separately by several means. The site publishes indexes and anthologies as well as weekly editions. Regardless of how an item of content is reached, the site displays an advertisement and maintains the site user's current location in a table of contents.
Management of the magazine suspects that a significant portion of their readership just browses the pictures directly without requesting the text of the articles. The facility is useful to track this phenomenon. Specifically, the facility determines the number of times a picture is requested outside of the context of its containing article.
In a first scenario, a user of the site goes to the ‘Travel in Hawaii’ article. The article contains a link to the Hawaii tourism site (external to the magazine), a link to another travel article about Fiji, and a ‘Hawaii-Travel.gif’ picture. In order to do so, the user performs the following:
The list of articles is generated by the web site's framework based on data from the corporate database. The framework also generates the client-side markup and script necessary to ‘pick’ the article. The client side framework formulates and sends the request to the server side framework to display the article.
In this example, directly displaying the article would violate business constraints of the framework. Specifically:
In addition, direct publication of the article without using the server-side component of the framework would allow non-subscribers to read it unless a separate security mechanism was generated.
Technically, this necessitates several changes to the HTML article to get it into the web site's HTML framework.
The HTML Rendering Facade is responsible for solving the problem of determining what to return to web framework when it requests parts for its web page. In this case, the HTML Rendering Facade is asked for a rendering that will fit within a HTML BODY tag. The facade:
Since the HTML Rendering Facade is specific to the HTML content type, the class can be written much more simply than generic rendering code which would have to handle multiple content types. As a result, it can be optimized to a greater extent than more general—and correspondingly more complex—rendering code.
It is important to note that the web framework requests HTML parts to render a HTML web page regardless of the content type of the article. While it would be trivial to change the Rendering Facade design to add an additional abstract factory parameterized on the rendering type (HTML, WML, HDML, . . . ), this would in some senses be disadvantageous, because rendering is very specific to the target content type. A great deal of over-abstraction is avoided by keeping the Rendering Facade interface specific to the target content type.
The URL Renderer Mediator transforms parts of the requested rendering to a form compatible with the web framework and business logic rules. In this case, the URL Renderer Mediator would:
Since the HTML Rendering Facade does all the work of identifying the links and describing their characteristics, the URL Renderer Mediator can achieve this complex business logic by implementing simple rules:
The use of the URL Renderer Mediator only to transform links is a reflection of the nature of web frameworks. The design could be trivially extended to include other identified components of the target rendering requiring transformation to comply with the framework and business logic. However, the treatment and use of links is central to the logic of web frameworks.
Because the HTML Rendering's mediator chose to use publishing for these links, the commands executed will go to the framework's publishing facility. The design requires a separate facility for publishing because published items are not transformed to fit within the context of a larger framework construct.
To publish a graphic, the framework:
The Publishing Facade is responsible for reading the input stream and rewriting it to the output stream. If links are present, the Publishing Facade uses the URL Renderer Mediator in the same manner as the rendering interface.
In this case, the URL Renderer Mediator might:
Note that in the case of most graphics, no publishing is required. In this case, the design allows for a single copy. This is no more than any proxying operation would require. Furthermore, the design allows for streaming. So, the entire published object need never be stored entirely in memory.
The case where graphics contain links is relatively obscure now, but this functionality is useful because:
In a second scenario, the user of the site goes to the ‘Hawaii-Travel.gif’ picture 541 directly. In order to do so, the user performs the following sequence of actions:
As with the ‘Travel in Hawaii’ article, the framework handles selection of the picture. The framework can do this using either the rendering mechanism or the publishing mechanism (2a and 2b below). This is a reflection of the orthogonality of the two sub-systems to the requirements of the web framework.
This functions exactly like rendering the article above except the ‘GIF’ content type's HTML Rendering Facade is used.
The ‘GIF’ content type HTML Rendering Facade might decide to implement inline rendering of the graphic by generating a command to display the graphic as the body content. Note that this algorithm is significantly different and a lot simpler than the algorithm for rendering HTML in HTML.
Since the details of handling the graphic are entirely encapsulated within the HTML Rendering Facade, the same URL Renderer Mediator could be used. This allows consistent business and framework logic regardless of the content type rendered.
This has the same result as the publishing of the picture from the first scenario, except that the tracking feature is not disabled. So, the user's action is counted as per business requirements.
In this way, the separation of the task into rendering and publishing allows the framework to implement logic based on ‘documents.’ This extends the web framework to work at a level above the resource (page and graphic) level that frameworks normally operate at without requiring it to know the intricacies of each content type it handles.
It will be appreciated by those skilled in the art that the above-described facility may be straightforwardly adapted or extended in various ways. While the foregoing description makes reference to preferred embodiments, the scope of the invention is defined solely by the claims that follow and the elements recited therein.
Number | Name | Date | Kind |
---|---|---|---|
5907837 | Ferrel et al. | May 1999 | A |
5986667 | Jevans | Nov 1999 | A |
6167409 | DeRose et al. | Dec 2000 | A |
6252677 | Hawes et al. | Jun 2001 | B1 |
6360360 | Bates et al. | Mar 2002 | B1 |
6631498 | McCauley et al. | Oct 2003 | B1 |
6697825 | Underwood et al. | Feb 2004 | B1 |
6704798 | Mogul | Mar 2004 | B1 |
6857102 | Bickmore et al. | Feb 2005 | B1 |
20010037412 | Miloushev et al. | Nov 2001 | A1 |
20020040314 | Tolson | Apr 2002 | A1 |
20020073202 | Wang | Jun 2002 | A1 |
20020083093 | Goodisman et al. | Jun 2002 | A1 |
20020099870 | Miller et al. | Jul 2002 | A1 |
20020102524 | Rizzi et al. | Aug 2002 | A1 |
20020188635 | Larson | Dec 2002 | A1 |
20030061305 | Copley et al. | Mar 2003 | A1 |
20030217061 | Agassi et al. | Nov 2003 | A1 |
20040059929 | Rodgers et al. | Mar 2004 | A1 |
20040205545 | Bargeron et al. | Oct 2004 | A1 |