System and method for data-driven web page navigation control   

Abstract: A system and method for web application navigation control includes updating navigation data models used in navigation constraints with received data from an end-user or system. Without needing a centralized application-specific controller, from a collection of extensible navigation rules associated with each page of a plurality of pages, the extensible navigation rules are automatically selected which depend on changed data values and need re-evaluation. The navigation constraints associated only with the pages potentially changing their ready state to execute from among the plurality of pages in an entire application are evaluated to determine which pages are ready to run based on updated data from the navigation data models. A preferred page to be actually navigated to next is selected from among a set of all available and ready pages by execution of a set of second and separate navigation constraints using results of the navigation constraints of the evaluating step.

This application is a Continuation application of co-pending U.S. patent application Ser. No. 12/847,484 filed on Jul. 30, 2010, incorporated herein by reference in its entirety.

1. Technical Field

The present invention relates to web page navigation control and more particularly to a system and method for automatically providing navigation through pages based on a position and/or content of data known or entered into a web form or page.

2. Description of the Related Art

Complexities result from a lack of integrated document packaging for current document formats which represent composite forms in collaborative business processes. Underlying document formats that flow through business processes typically are existing formats such as PDF, DOC, HTML, or various proprietary XML formats. Proprietary, or vendor-centric, formats are not suitable representations for complex composite forms due to the closed nature of their formats. Complex forms require new or extended representations for issues such as data sharing across document fragments, transfer of control among fragments, electronic signatures that span document fragments, and style sheets for coherent presentation and interaction.

When large form applications are based on an XML file format, they are somewhat open and interoperable. Use of a custom XML vocabulary, when implemented in plug-in or other runtimes separate from web browsers, often limits access to the full power of well-known web resources that customers expect to be able to use, such as CSS™ and JavaScript™

Web formats today, such as HTML, do not support packaging of composite resources directly—the page is the unit of content storage. Hyperlinks permit navigation among related resources but do not define collections of related content. Formats that collect related artifacts including HTML pages, images, and metadata into internally coherent entities are intended for archiving websites for historical or offline purposes, not as runtime platforms.

Most solutions to the packaging of composite web applications therefore are specific to the middleware platform on which the web application is deployed. Web application archive format (WAR) files are used by JEE web application servers to package and deploy the set of artifacts needed by a given web application including HTML pages or the Java Server Pages that create them, Java beans for storing and validating data during user interaction, and static resources such as images.

JEE web applications commonly include flow-based controllers such as Struts to control the internal behavior of the various artifacts included in the WAR file and to invoke back-end services as required. Generally, web archive (WAR) files define a packaging mechanism for composite web applications, but they do so in a platform-specific (JEE) way. Such archives are not transportable to other runtimes including non-JEE application servers or client-based runtimes.

Going beyond packaging formats, web archive files are deployment not runtime artifacts and hence do not define a network access protocol, or URL pattern, for accessing their contents. Web archives similarly provide no support for aggregating multiple content sources when several end-users are involved in a document-centric business process.

The emerging W3C format for widgets makes similar use of zip-based archives for packaging but, as in the JEE WAR example above, lacks requirements or support for an interactive protocol or instance-specific data storage. URI standards being defined for widgets are intended to resolve references internal to the widget from one resource to another. Prior work on composite document packaging focuses on adapting document content for rendering to multiple devices.

In traditional workflow, the token of control is the central focus and content (whether in documents or otherwise) flows through the process from one artifact to another as a result of the execution of a control path defined by the workflow. Documents and document behavior become secondary to control flow.

High level declarative languages for control are required just as they are for data and presentation. Many of today\'s complex forms processing systems require authors to “escape out” of their document-centric languages when describing behavior, even to manage document presentation and validation in single workflow steps with individual users. Document-centric formats that do not extend to behavioral control increase complexity due to the need to map repeatedly between declarative and procedural programming models.

Declarative languages for document behavior may nonetheless be expressed in multiple conceptual models, including flow-based languages with adaptations for human interaction, state-based languages, and time-based languages. These declarative languages share the advantage of being independent of the specific runtime middleware platform being used to support the composite web application.

Without a simple means to represent large or complex forms as composite documents, monolithic documents result in performance and scalability limitations, particularly on a logical client. Large documents are slow to transmit, parse, and display and consume large amounts of storage. When large forms applications are represented with a single XML document, the result is excessive, and sustained demand on memory resources is needed to provide a performant user experience. This is demanding on a rich client program, but it is even more demanding when the logical client includes a server program to present the parts of the document to an end-user through a web browser. The server side of the solution has the same performance challenges as a rich client for one user, but also does not scale up beyond a few dozen concurrent users per CPU.

The processing associated with a complex document may take place at multiple locations in a distributed system. End-users may interact with rich or thin clients. Web services may augment document content from the server. Intermediaries may transform document content in the network. The decision as to where to perform each document operation should be decoupled from how the document is represented to allow for “late binding” or alternative choices in how document processing is deployed onto a particular infrastructure. Lightweight means to provide language extensions to current browsers have been developed based on the use of JavaScript™ as an XML tag library implementation language rather than as the direct authoring language for web pages.

SUMMARY

A system and method for web application navigation control includes relating data entry fields in a page stored in computer readable storage memory with non-procedural computed dependency constraints that provide navigation control when a condition is met. A presence of user-side information is checked to determine if the condition is met and the indicated navigation control is to be invoked. If the condition is met, a trigger event is evoked to navigate to a new page based on at least one of a set of entry fields where data was entered in and a type of data content entered in the entry fields without guidance from procedural navigation code.

A system for web application navigation control includes a server including a dependency graph relating data entry fields in a page with a navigation instruction that provides navigation control when a condition is met. An interaction module is configured to be sensitive to at least one of user-side information entry and known information to determine if the navigation instruction is to be invoked. A processor is configured to execute the navigation instruction in accordance with a presence or absence of data values or conditions over those values to navigate to a new page based on at least one of a set of entry fields data was entered in and a type of data content entered in the entry fields without guidance from procedural navigation code.

A system and method for web application navigation control includes updating navigation data models used in navigation constraints with received data from an end-user or system. Without needing a centralized application-specific controller, from a collection of extensible navigation rules associated with each page of a plurality of pages, the extensible navigation rules are automatically selected which depend on changed data values and need re-evaluation. The navigation constraints associated only with the pages potentially changing their ready state to execute from among the plurality of pages in an entire application are evaluated to determine which pages are ready to run based on updated data from the navigation data models. A preferred page to be actually navigated to next is selected from among a set of all available and ready pages by execution of a set of second and separate navigation constraints using results of the navigation constraints of the evaluating step.

These and other features and advantages will become apparent from the following detailed description of illustrative embodiments thereof, which is to be read in connection with the accompanying drawings.

The disclosure will provide details in the following description of preferred embodiments with reference to the following figures wherein:

FIG. 1 is a diagram showing a monolithic document decomposed and aggregated into an interactive web document (IWD) in accordance with the present principles;

FIG. 2 is a diagram showing resources using svc attributes with relative URIs to access other resources in a same IWD;

FIG. 3 is a diagram showing an illustrative page navigation submission sequence;

FIG. 4 is a diagram showing submission patterns for IWD interaction control;

FIG. 5 is a diagram showing an interaction controller submission sequence for interaction control based page navigation;

FIG. 6 is a diagram showing submission patterns for IWD interaction control using logical navigation targets;

FIG. 7 is a block/flow diagram showing a system/method for web page navigation control in accordance with one illustrative embodiment;

FIG. 8 is a block/flow diagram showing a system/method for web page navigation control in accordance with another illustrative embodiment; and

FIG. 9 is a block diagram showing a system for web page navigation control in accordance with another illustrative embodiment.

DETAILED DESCRIPTION

In accordance with the present principles, systems and methods for unifying storage and management of various artifacts for web applications and the like into an Interactive Web Document (IWD) are illustratively provided. Documents allow end-users to encapsulate information related to a collaborative business process into a package that can be saved, emailed, digitally signed, and used as the basis for interaction in an activity or an ad hoc workflow. While documents are used incidentally today in web applications, for example, in HTML presentations of content stored otherwise in back-end systems, they are not yet the central artifact for developers of dynamic, data intensive web applications.

The storage and management unification of the various artifacts of web applications into an Interactive Web Document (IWD) provides that data, presentation, behavior, attachments, and digital signatures collected throughout the business process are unified into a single composite web resource. A standards-based approach to packaging multiple resources into IWD archives based on the Open Document Format, a REST-based protocol for interacting with IWDs, and an extensible interaction controller architecture are illustratively described.

In accordance with the present principles, web application navigation control is provided by updating navigation data models used in navigation constraints with received data from an end-user or system. Without needing a centralized application-specific controller, from a collection of extensible navigation rules associated with each page of a plurality of pages, the extensible navigation rules are automatically selected which depend on changed data values and need re-evaluation. The navigation constraints associated only with the pages potentially changing their ready state to execute from among the plurality of pages in an entire application are evaluated to determine which pages are ready to run based on updated data from the navigation data models. A preferred page to be actually navigated to next is selected from among a set of all available and ready pages by execution of a set of second and separate navigation constraints using results of the navigation constraints.

As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing. Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user\'s computer, partly on the user\'s computer, as a stand-alone software package, partly on the user\'s computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user\'s computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

Aspects of the present invention are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

A new composite document format called Interactive Web Documents (IWDs), based on reuse of existing standards such as the Open Document Format (ODF) packaging format is described. The format collects together all artifacts of a complex form moving through a business process. In addition, a REST-based protocol is defined for interacting with IWDs at runtime. A standard format for office-based documents (ODF) provides an archive format for packaging the various artifacts relevant to an office document, including content, style sheets, and images, along with a manifest itemizing those assets.

IWDs extend ODF packages in two ways: first, they reuse the ODF package format for interactive documents by defining a mapping between REST-based requests over the web into the internal artifacts stored in the archive. This mapping allows IWDs to maintain their identity as integrated resources. The second extension IWDs make to ODF archives is to allow for additional artifacts relevant to interactive forms, including (X)HTML pages, additional style sheets, documents defining data models (e.g. using XForms models) and declarative controllers managing transitions among these artifacts as the document executes. IWDs thus are containers for a set of smaller subdocuments, each of which can be served and rendered more quickly than the complete monolithic document while providing control over the navigation among the included documents and aggregation of data results from each.

The IWD architecture defines not only how IWD artifacts are stored internally in their ODF-based archive, but also how they interact with the external environment using a REST-based protocol. IWD runtimes support a set of URL patterns for REST-based interaction including GET, PUT, POST, and DELETE operations on documents inside the IWD resource. IWDs thus are well-behaved web resources and can be served by any web platform (client or server) able to support its REST protocol. Client-based access may be made directly to IWDs hosted by rich clients or remotely to IWDs served to a web browser or other thin client. Server-based middleware used to implement the backbone business bus over which IWDs execute in a business process likewise can manage IWDs using the same interface—treating the Interactive Web Document as a service.

The document-centric approach to forms applications is popular with both end-users and application developers. A new file format and processing model for describing rich interactive forms applications that preserves their document-centric nature while also better accommodating their memory and performance demands is presented in this disclosure. The file format itself is based on the ODF standard and (X)HTML web pages, while the rich, secure processing model is based on XForms and XML Signatures.

Referring now to the drawings in which like numerals represent the same or similar elements and initially to FIG. 1, a monolithic document 101, its decomposition and aggregation into an Interactive Web Document (IWD) are illustratively depicted. Resources comprising a web application are stored within a single compressed archive file 100 that conforms to the ODF package format. As such the archive file 100 also includes an internal indication 102 of its content type and a manifest 104 of its resources, and their content types. FIG. 1 depicts the simple transition from a single, monolithic XML document 101 to the new Interactive Web Document (IWD) format 100.

A monolithic form document 101 stores in a single XML document all images 108, all supporting document attachments 110 provided by end-users, all XML data instances 112 and business rule models 114, all scripts and style-sheets 116, all web pages 118 needed for various wizard experiences, and all pages or other files which may be needed for high-precision “contractual” views and “print” views of the business function. In the Interactive Web Document 100, these resources are aggregated, yet their decomposition remains within the ODF package. Aggregating the resources enables the document-centric business process, and preserving the decomposition enables better design tooling, and it also enables the components to be addressable as separate resources via a REST service interface.

An application developer has the option of placing the data models (Mn) 114 into the web pages 118 rather than separating them out, thus allowing optimizing and tailoring the client-side business rules to control just what is on each page. The XML data instances (Dn) 112 are in separate files, and the many web pages (Wn and Fn) 118 and 116 that may be needed to complete the business function are in separate files, each capable of sharing access to the XML data files in the package by simply referencing them with the src attribute of an <xforms:instance> (see below). Each of the web pages 118 (116) can permit the user to transition to any other web page in the document using an <xforms:submission> (see below), which also permits the next page to be determined dynamically from user input.

In lieu of directly expressing page transition instructions within the web pages 118, application developers may formalize the state transitions of the Interactive Web Document into a centralized interaction controller (IC) based, for example, on State Chart XML as described herein.

IWD Metadata: According to the ODF packaging format, the file which may be regarded as the root of processing is called content.xml. Other current ODF formats are used to contain the results of a rather passive and relatively free form user interface experience (e.g., text editing), and the contents of the content.xml file are appropriate to that task. In the case of an Interactive Web Document, the ODF package is intended to aggregate the web application resources needed to perform a business function, and content.xml contains information relevant to that purpose. This can include: 1) an indication of the current web page on which to begin processing when the Interactive Web Document is launched; this setting initially indicates starting web page, but it can be adjusted whenever the user navigates to a new web page in the IWD; 2) the base URI of the server from which the document was first obtained; this setting is only automatically set if it is empty and the document was obtained from the web; 3) a document-level definition for the resources (e.g. PDF/A documents or web pages) that comprise the print view of the document; 4) an IWD template identifier to help easily determine the IWD template from which this IWD was instantiated; this setting helps optimize instantiation by enabling the ability to only instantiate IWD components that differ from the template; 5) a globally unique identifier (GUID) for the IWD to help track the IWD through a multi-user collaborative process; 6) an indicator of a centralized interaction controller file that helps manage the state of the IWD; 7) other IWD metadata, such as information about an IWD-internal cache of content from externally referenced URIs.

Although it is also feasible to store the shared data of an IWD in content.xml, the variation illustratively discussed herein uses separate data files as this simplifies both IWD authoring and the REST interface for the IWD. The metadata element indicates the current web page on which processing begins. As a result, the following markup provides an example of the content.xml file of an IWD:

<odf:document-content Dn   xmlns:odf=“&odfns;”>  <odf:office-body>    <iwd xmlns=“&iwdns;”>     <current>Page1.html</current>    </iwd>  </odf:office-body> </odf:document-content>

Package-Relative Referencing: Many web-based technologies use URIs to enable a document to obtain or reference related web resources. A simple example is the src attribute on <img> and <script> tags in (X)HTML web pages. The web technologies used within an IWD are further equipped with a relative URI dereferencing facility that enables access to resources within the IWD that are positioned relative to the referencing resource.

Referring to FIG. 2, a diagram of a simple IWD 130 comprised of two web pages (Page1.html and Page2.html) 132 and 134, two data files (D1.xml and D2.xml) 136 and 138 and an image (Logo.png) 140. If Page1.html is stored in the root directory of an archive, and a file Logo.jpg is stored in an images subdirectory, then a web page can display the logo image using the following markup:

<img src=“images/logo.jpg” /> Wn Fn

Similarly, FIG. 2 shows that web pages can use an XForms element called <xf:instance>, where xf is bound to the XForms namespace, to access an XML data model, and that element also supports an src attribute. As a result, the following markup can be used to import the data file D1.xml from a data subdirectory into a web page in the root directory of the archive:

<xf:instance id=“d1” src=“data/D1.xml”/> Mn

Run-Time Behaviors of an IWD: Session Instantiation: There are a number of ways in which a user can begin interacting with an IWD. The user could click an anchor link to the IWD template or the user could make a request of a server endpoint that returns an IWD template or perhaps an IWD that has been partially completed in a prior session. In all these cases, the IWD content type on the outbound result is detected, and the content is rerouted to the IWD server via a POST operation. Rather than delivering the entire binary ODF package for the IWD, this operation creates an interaction session for the IWD and then returns a redirection page to the end-user that requests the <current> web page from the session-qualified IWD.

The act of instantiating an IWD interaction session consists of logically exploding its file resources into a unique directory determined dynamically at the time of the request. All further interactions on the IWD by the end-user are channeled through a session ID associated with that directory by the IWD server implementation. This permits any number of users to instantiate any number of IWDs since each instantiation results in a unique session directory. Note that if the IWD provides a template identifier, then rather than physically storing a copy of all files in the IWD, it is possible to detect which files differ from the template and to store only those. Requests for unmodified files are answered with content from the template. Once the IWD interaction session is created, access to IWD resources is channeled through the session-qualified URIs of a REST API that provides the standard CRUD operations (create, read, update, delete).

Data Sharing across Web Pages: Web pages are able to use XForms user interface bindings to enable the end-user to access and, depending on the form control, modify data stored in an XForms instance. In a single web page application, the XForms instance can contain the data as inline content. However, to share data across web pages, the data is stored in a data file in the IWD. For example let the file D1.xml in a data directory of the IWD contain the following content:

<policy xmlns=“”> Dn  <name>Kazimierz Kuratowski</name> </policy>

The data is then imported into a particular web page using the src attribute of the <xf:instance>, which makes the data content available via XPath referencing regardless of whether it was obtained from inline content or an external resource as follows:

<xf:instance id=“d1” Mn

Download full PDF for full patent description/claims.




You can also Monitor Keywords and Search for tracking patents relating to this System and method for data-driven web page navigation control patent application.

Patent Applications in related categories:

20130125005 - Contextual data displayed via browser toolbar - A browser toolbar displays contextual data from a search engine service for a webpage currently being displayed by a web browser. The browser toolbar identifies the URL of a webpage currently being displayed by a web browser. The browser toolbar provides an indication of the URL to a search engine ...

20130125006 - Protocol sensitive visual navigation apparatus - Embodiments of this invention include a protocol sensitive visual navigation apparatus, and associated methods, for navigating and relating different protocol levels of a protocol. A test and measurement instrument can include the protocol sensitive visual navigation apparatus, which can facilitate analyzing, searching, and measuring various aspects of the different protocol ...

20130125007 - Remote access to layer and user interface elements - A user-activatable dashboard (also referred to as a unified interest layer) contains any number of user interface elements, referred to herein as “widgets,” for quick access by a user. In response to a command from a user, the dashboard is invoked and the widgets are shown on the screen. The ...


###


Other recent patent applications listed under the agent International Business Machines Corporation:

20090327627 - System, method and computer program product for copying data
20090328229 - System, method and computer program product for performing a data protection operation
20090310462 - Frustum-shaped holographic disc and matching tray in a holographic drive
20090296267 - Apparatus and method for writing data onto tape medium
20090296268 - System and method for controlling traveling of tape