Below is a proposed idea I wrote in response to my frustration with the stateless nature of the web (which it was intended to be) attempting to now become a stateful, application-friendly environment.

Statefulness and State Transitions through Transitional Markup Language

Abstract
Web applications have progressed significantly over the years. Once limited to simple scripting, technologies have now evolved to give web-based applications near desktop application-like power. Yet, in the midst of these advances one aspect of web applications has plagued the industry. The interface. The layout definition methodology (HTML) and the medium of delivery (the internet browser) were not originally intended to deliver the kind of rich interactive applications web users now desire.

Methodologies have been implemented to attempt to remedy some of the interface dilemmas web application developers face. Cascading Style Sheets (CSS) were introduced as a standard to attempt to separate layout from HTML, giving greater and more streamlined control over visual appearance. Javascript, a "client-side" (or "browser-side") programming language was introduced, intended to try to mimic desktop application delivery through in-browser code.

The latest efforts are to use one of Javascript's abilities (the ability to generate an HTTP post in code on the browser) to effectively request new page content without actually "refreshing" the page (i.e. forcing the browser to make the request the standard way). This methodology, called "asynchronous postback", is the core of AJAX (a general term describing the attempt to make "refresh free" web applications) which is one route developers are taking to attempt to make web applications more like desktop applications.

These ideas however, while admirable and quite powerful, are workarounds which do not face the real issue. The issue is that the core technology, that is to say HTML and the internet browser, are being used in a way that they were never intended to be. For web applications to every truly become as rich and user-friendly as desktop applications, it is that issue that must be addressed.

Another issue in regards to current web applications is the difficulty of making said applications accessible to all users. The goals of interaction and clear response are not easy to implement when taking into consideration those users with disabilities. A more generalized approach is needed to building interactive pages that, while still allow for competition through varied interface options, generalize these interfaces for interpretative clarity.

For these reasons, we introduce two new core concepts designed to rectify the inherent weaknesses of HTML and the current internet browsers. The first is a new XML-based structure which we call Transitional Markup Language (or TML). The second is the TML stateful browser. We will loosely define both in this document, and expound on ideas for implementation.


The Weaknesses of HTML and Internet Browsers
The Hypertext Transfer Protocol, the Hypertext Markup Language and the HTML browser were brilliant concepts. The World Wide Web which they have brought about has changed the world as we know it. The Hypertext Transfer Protocol is an excellent and simple medium for data exchange, and we do not propose to changing it. Yet, there are inherent weaknesses in the HTML / HTML browser paradigm in regards to constructing powerful web applications.

Weakness #1: Statelessness:
HTTP and the HTML browser are inherently stateless constructs. There only intention was to receive data requests, and return data responses. There is no concept of state across multiple requests and responses. All statefulness implemented in any web application framework is shoehorned into the HTTP request and response structure. Rich software applications require statefulness. Thus statefulness should be an inherent part of the construct.

Weakness #2: Large and Visible Transitions:
The internet browser builds HTTP requests and outputs the response. Current browsers, therefore, rebuild an entire request and then return the entire response during each transaction. This causes, in many cases, more information than necessary being sent across the wire. These requests are also "visible" to the user. That is, the user is often presented with a white screen while the request and response transaction is being carried out.

Thus, any approach to solve these weaknesses must enforce statefulness between requests and responses, and small, invisible transitions between said requests and responses.


Goals of TML
The goals of TML are as follows:

1) Stateful Construct: To define a markup language and server structure which is inherently supports statefulness across requests.

2) Markup Generality: To define a structure which generalizes types of content, thus enhancing search and delivery efficiency, while using various attributes to specify said generalizations.

3) Low Bandwidth Usage: To define a structure which inherently uses smaller amounts of bandwidth by minimizing the amount of information being transferred.

4) High Accessibility: To define a structure which eases and promotes higher accuracy of interpretation, thus enabling software to more easily and accurately represent a webpage to all users, no matter what the interface needs require.


Transitional Markup Language (TML)
Transitional Markup Language is an XML-based language designed to be interpreted by an HTML browser and by an HTTP server with the goal of delivering rich content via the Internet. TML defines a methodology to allow browser and server communication to be stateful and minimize the size of transitions from request to response.

A) The Root
Each TML document would define a TML page. The common structure of a TML page would appear as follows:

The root tag of a TML document is the PAGE tag. Each page may have one title, many META tags (such as to describe keywords, a description, etc.), and many STYLESHEET tags (to define external stylesheets). The core of the TML page, however, is what is contained in the STATEBAG section.


B) The Statebag
The STATEBAG is a collection of regions, defined by the REGION tag. The statebag is identified by a guid which is to be provided by the server upon first request, and will be delivered back to the server on each subsequent request. The browser would persist this state bag guid ID through all requests as long as the user remained inside the same internet domain name.

B1) The Region
All rendered elements of a TML page are defined within a region. A region is specified by an ID unique to the page, and a type. A region may be of a type bucket, text, button, image, textbox, dropdownlist, multiselectlist, radiobutton, checkbox, or video. Within the region will be defined an INTERFACE, CLASS, and CONTENT. A region of type bucket would have no interface, or content. It is merely designed to identify multiple regions as being related:

A region may also contain one or more EVENT tags.

B1a) The Interface
The interface is a method of defining the interface to a particular type.

For example, a region of type text may have an interface of hypertext (which may contain hyperlinks, carriage returns, paragraphs, span tags, and anchors), PDF, or RTF.

A region of type button may have an interface of button, or image.

A region of type image may have an interface of type JPG, GIF, PNG, or BMP.

A region of type video may have an interface of type Quicktime, RealPlayer, WindowsMedia, or Flash.

Form type regions (textbox, dropdownlist, multiselectlist) have no interface.

Thus the placement of an image would appear as follows:

The list of valid interfaces for all types may be extended by plugins installed into the browser.

B1b) The Class
One goal of TML is to have no aspect of its structure define the layout of the page. All layout would be done through current or future Cascading Stylesheet (CSS) specifications. The CLASS section would either be the name of the CSS class defined in an external stylesheet, or inline CSS.

B1c) Content
The CONTENT section contains either text (in the case of a region of type text, or of type button if the button uses a button interface), or a file reference (in the case of regions of type image, video, and possibly button if the button uses an image interface). Thus, assuming an external stylesheet is referenced, a text and an image could be placed as follows (using both external CSS for the text and inline CSS for the image):

B1d) Events
TML provides a methodology for loosely defining events and event delegates in its structure. We use the term "loosely defining" because it is up to the framework on the server which delivers the TML to decide what said delegate actually is implemented as (unless the delegate is defined as a state transition). An EVENT tag may contain one or more DELEGATE or STATETRANSITION tags. Each event will have a defined type. Events may be of various types, such as Render, Click, DragStart, or DragStop. This list would comprise any event the browser could capture.

B1d-1) Delegates
For any event, one or more delegates may be defined. A delegate is nothing more than an ID which will be passed to the server. The server will likely relate said ID to a block of code to be run. For example, the delegate may be a method name, and the method will thus be executed on the server. An event with a delegate might appear as below, defining events on a button in a TML page:

A event may also directly trigger a state transition.

B1d-1a) State Transitions
A STATETRANSITION is nothing more than a series of regions, just as are held in the STATEBAG tag. However, the state transition holds only the updated information (i.e. the updates that should be made to the state bag itself). Thus, for example, if one wished to update the text of a button upon clicking it, the TML page might appear as below:

Note that the STATETRANSITION hold the ID of the state bag it is updating. In the case of the above example, clicking the button would cause the button's text to change from "Click Here to Submit" to "You clicked me!", and the CSS class to be updated from the "standardButton" class to the "redButton" class. Regions in the STATEBAG and regions in the STATETRANSITION are matched by their IDs. Thus a state transition is of the exact same format as the state bag. You could add new regions, change others to invisible through CSS, update text, images, etc. A state transition could even add new browser-side state transitions to events.

Thus, Transitional Markup Language is a layout-free, stateful XML representation of a rich document which could be delivered to a TML browser. It is important to note that TML does not allow for scripting languages of any kind. The state transition contained within an event is the limit of its dynamism. It is designed to leave more complex actions and processing to the server.


The TML Browser
A browser which parses, interprets, and renders TML would abide by the following criteria:

State Storage:
The browser would store the "statebag" of the user for the page he or she is currently viewing. It would update the statebag according to state transitions either embedded in the TML, or received from the server. The browser should persist the statebag until the state transition requires a new page to be loaded. This statebag should be persisted even if the internet connection is lost, so that stateful interaction can continue if the connection is reestablished before the server destroys or reassigns the thread. 

Asynchronous Postback:
All HTTP requests to the server would be done asynchronously by the browser. Upon receiving the response from the server, the browser would act to update the statebag and rendered items.

State Transition Postback:
The browser would asynchronously update the server, via a STATETRANSITION sent through HTTP, in response to all actions made by the user. Thus, if the user typed a value into a textbox, a STATETRANSITION would be sent to the server asynchronously specifying the textbox region's new CONTENT. For example, if the TML page defined an empty textbox with an ID of "textbox1", and the user typed a value into the box, the following would be sent asynchronously to the server by the browser:

Also, any state transitions defined in the TML page itself as the result of an event would be also sent to the server (although the browser would instantaneously implement the transition), so that state remains equal on both the browser and server side. In this way the server would be always kept up to date with the actions and current state of the user.

"Browser-side" State Transition Event Handling:
The browser would update the state of the page based on STATETRANSITION tags in response to their associated events. The browser would also send said transition to the server, so as to keep the server and browser's state bags in sync.

"Server-side" State Transition Response Handling:
The browser would expect a STATETRANSITION or a new PAGE as a response to a request or state transition that the browser itself sent. If, in response, a state transition was received from the server, it would update the local state bag and render accordingly.

Partial Rerendering:
If, after receiving a state transition, any aspect of the updated statebag required an area of the page to be rendered, the browser would only update that area without requiring the entire TML document to be rerendered.

Video State:
Video players should provide a method for the browser to include in the state bag the current time or frame of the video. This way the state bag could truly reflect what the user is seeing on the screen. The browser should then, if the state bag specifies a time or frame on a video, begin said video at that time or frame. The tag might appear as follows:
 

Bookmarked State:
To "bookmark" a page in a TML browser means to bookmark the page according to its current state bag, thus allowing the user to return to the page exactly as it was when left. This would include the video state as mentioned above.

HTML Backward Compatibility:
It would not be prudent to simply attempt to replace HTML. Thus, any TML browser should also be an HTML browser, possibly differentiating based upon HTTP header information.


The TML Server
The server or server utility which delivers TML would define a session space (an area in memory on the server dedicated to a particular user) for any browser requests which do not contain a state bag ID (these would be assumed to be new requests). The server would hold a state bag, which would be a duplicate the state bag held in memory by the browser. It would update its state bag with any STATETRANSITION messages sent from the browser - it would then execute any required code, update its state bag, and return its own STATETRANSITION to inform the browser of the updates it has made.

A new state bag would be made from the TML code on the page sitting on the server during the first request, and a state bag ID would be generated. Within the first STATETRANSITION response sent from the server to the browser, and all subsequent responses, the state bag ID would be included. For subsequent requests from the browser, the server would pull the state bag from memory based on the state bag ID passed by the browser.

The server or server utility should consider all requests from a particular state bag ID in a first-in, first-out (FIFO) manner. Each request would be considered and responded to in the order received.


Accessibility of the TML Model
The TML model also has the goal of easing accessibility issues in regard to web-based applications. The structure of todays web applications make rendering them accessible to those with disabilities a challenge. The accessibility challenge involves allowing for ease of interaction, and expression of response to that action. By simplifying and standardizing interface types, and by clearly structuring transitions, accessibility tools could be built to convey to the user the responses to their actions. The interfaced, regionalized structure also would allow for a "generic" approach to describing various pieces of the TML page. Browsers designed for maximum accessibility could separate out individual regions based on type in order to present them in the best possible manner to a specific user.


Conclusion
Thus, we have a brief overview of Transitional Markup Language and the TML browser and server. The goal is to provide a layout-free, stateful messaging system that can still travel across HTTP. This model also has the goal of decreasing the load of web traffic by only sending needed data (state transitions) between browser and server, rather than entire page constructs with each request. This structure also has the goal of maximizing accessibility for all potential users.

Is this model reasonable to implement? Dynamic frameworks (such as PHP, ASP, or ASP.NET) already provide the session concept. These constructs (which "handle" HTTP requests and responses) could be extended to receive and deliver TML state transitions. These technologies could then take advantage of the inherent statefulness of the TML construct.

The technology also exists to create a TML browser, which would inherently hold the state bag, postback asynchronously, and send and respond to state transitions. It is our goal to suggest a roadmap for addressing the issues with current web application frameworks, which are limited by HTML and HTML browsers, allowing for the dynamism and user interface complexity provided now in desktop applications.


--Author: Anthony P. Alicea
--Copyright: 2006

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License.