This brief document proposes an XML application for describing user interfaces. This general purpose XML application can be used in a variety of situations, but is especially intended for use in future versions of the Navigator based on Raptor. As such, a description of the binding between XUI and Raptor is also provided.

Assumptions

1. Assume that RDF serves as the proxy for virtually all remote data. This includes the binding to UI resources such as images, cursors etc.
2. Assume that we will use Javascript to provide dynamic behaviors to whatever degree is reasonably possible. Inevitably, some behaviors will be provided intrinsically by native widgets and others by the Raptor layout engine.

Or rather, why not pure HTML? A simple set of criteria were used:

• To make processing easy, a well formed structure is assumed.
• It is acknowledged that a document transformation would be neccessary to convert from the UI specification grammer to something concrete in our content model. The transformation will be simpler if we control the schema.
• Find a schema that carries as few implied semantics as possible, preferably none.

NOTE: It is expected that subportions of the UI can and will be expressed as HTML which will occur as embedded tags within the XML. But the highest level structures most likely will not.

The Schema

To effectively construct a contemporary UI in XML (or any other schema), it is necessary to provide sufficient richness to describe the manipulatable elements, content, layout and constraints, behaviors and style. The remainder of this section of the document represents an attempt to define such a schema.

Manipulatable  elements

Either simple or aggregated "controls" that may be directly manipulated by the end user.

The minimum set of controls includes static and editable text controls, buttons (push, popup, radio, checkbox), toolbar, listview, treeview, menus (standard and popup), splitter bars, scrollbars, status bars, spinners and tooltips. A brief schematype is provided for each below:

Element	<text></text>
Attributes	type	static, edit
	label	"..."
	listener	app, handlerID, this
	action	notify, close, ...
Contains	<img>, <tooltip>

Element	<button></button>
Attributes	type	push, popup, text
	label	"..."
	listener	app, handlerID, this
	action	notify, close, ...
	statusmsg	"..."
Contains	<img>, <tooltip>

Element	<toolbar></toolbar>
Attributes	align	top, bottom
	label	"..."
	dockable	true, false
Contains	<button>, <spacer>, <text>, <menu>, <tooltip>

Element	<listview></listview>
Attributes	type	bigicon, smallicon, detail
	label	"..."
	src	data source url
Contains	<tooltip>

Element	<treeview></treeview>
Attributes	type	static, edit
	label	"..."
	src	data source url
Contains	<tooltip>

Element	<menubar></menubar>
Attributes	align	top, bottom
	listener	app, handlerID
Contains	<button>, <separator/>

Element	<menuitem></menuitem>
Attributes	label	"..."
	listener	app, handlerID, this
	action	notify, close, ...
	accellerator	"..."
	statusmsg	"..."
Contains	<img>, <tooltip>

Element	<splitbar></splitbar>
Attributes	type	static, moveable
	align	vert, horiz
Contains	default text value

Element	<scrollbar></scrollbar>
Attributes	align	left, right
	label	"..."
	listener	app, handlerID
Contains	<tooltip>

Element	<statusbar></statusbar>
Attributes	align	top, bottom
	label	"..."
	dockable	true, false
Contains	<tooltip>, <toolbar>, <menu>, <button>

Element	<spinner></spinner>
Attributes	default	1..n
	range	1..n
	listener	app, handlerID
Contains	<tooltip>

Element	<tooltip></tooltip>
Attributes	label	default text value
Contains

Element	<htmlarea></htmlarea>
Attributes	align	top, bottom, left, right, center
	width	pixels, percent
	height	pixels, percent
Contains

Element	<panel></panel>
Attributes	label	"..."
	width	pixels, percent
	width	pixels, percent
Contains	*

Content

Data provided by a datasource that is eventually rendered into the set of maniuplatable elements

In the XUI universe, we expect content to come from three sources:

1. The HTML content model
2. An RDF datasource
3. The user (assuming an editor)

This approach assumes that Raptor itself will provide the constraint-based layout process used to handle the layout of the user interface. In particular, it is expected that Raptor tables will be used, albeit with a few minor modifications.

Element	<constraint></constraint>
Attributes	align	top, bottom, left, right, center
	autosize	true,false
Contains

Behavior

The programatic interaction between the user and the manipulatable elements, as well as between these elements and other aspects of the UI.

Behaviors come in intrinsic and extrinsic forms. Intrinsic behaviors refer to the inherent behaviors found within a given UI contol. For example, a tree control inherently offers selection, scrolling and expand/collapse of nodes.

Extrinsic behaviors refers to programmatic behaviors that are constructed at runtime. These behaviors typically bind a known event within a control to an external observer that is notified upon with each occurance of that event. It is anticipated that event notification will occur either via notification interfaces or through the use of Javascript.

<insert information about extrinsic properties here...>

Style

The set of dynamic alternatives with regard to all three major aspects of the UI working set. Often it is used to describe a dynamic change in a typographic sense, but it can also refer behavioral changes as well.

This model assumes that style is bound to both manipulatable elements and behaviors either via CSS selectors or through direct stylistic attributes encoded within the appropriate tags.

Overview of the XUI Process Model

This section of the document will briefly describe all the processes involved in consuming, storing, laying out and rendering of an XUI/XML document.

Step 1: Consume the XUI document

As with any content type, a XUI document is identified during the parse process by XUI-DTD. Once bound, the XUI-DTD coordinates the parse/tokenization process. Text from the XUI document are parsed into the appropriate tokenset and given to the XUI-DTD for further processing. This step is trivial, and examples already exist within the Raptor framework that demonstrate this capability.

Note that the entire XUI element tree is cached by the XUI-DTD for further processing. This is unlike the normal content production process, where little or no caching occurs. It is anticipated that very little performance impact will be detected since XUI documents will typically be very small. (See the example at the end of this document).

Step 2: Transform the XUI elements into HTML

One the XUI tags have been parsed into tokens, the XUI-DTD then performs an analysis and transformation phase. The XUI elements are converted into the appropriate set of corresponding HTML elements where possible. The transformation rules are inherent in the XUI-DTD, rather than by a corresponding XSL-type process.

Step 3: Update the Separate UI content model

The HTML elements produced by the XUI-DTD element transformation are sent from the DTD via the appropriate protocols to the HTML content sink. Because we begin all such transactions with a call to OpenUserInterface(...), the content sink can easily tell that it is receiving UI content. Subsequently, the UI content model can be kept separated from the main document content model. After the UI elements have all been sent to the sink, the DTD will notify the sink via the CloseUserInterface(...) call.

Step 4: Layout and render the UI

The final step in the process is to cause the document to layout and render the UI content model that it has been given. It is expected that with few changes, this process will look identical to the normal processes involved in laying out and rendering the main HTML content model.

Note that this process does not assume a unique layout manager. Ultimately, a table will wrap the UI elements in the UI content model, and our existing layout processes should suffice.

Integrating the XUI Schema with Raptor

Integrating the XUI schema with Raptor requires only a minimum set of changes. This set includes changes to the parse system, the DTD, the content sink, the content model, the document and finally the DOM. Each of these is described below.

Parser Changes

The first change required to integrate XUI with Raptor occurs at the parser level. At a minimum, we must ensure that the existing HTML token set is updated to handle any XML style extensions required to conveniently express the XUI schema. At this time, no such extensions are expected.

DTD Changes

Our existing NavDTD needs to be subclassed to create a XUI-DTD. This DTD will cache all incoming tokens. Once fully tokenized, the XUI-DTD will iterate its token cache, and transform the elements into a set of well-formed HTML elements. Next the sink is opened with a call to OpenUserInterface(...), and then the transformed HTML elements are written. The last step will be to call the corresponding sink method, CloseUserInterface(...).

ContentSink Changes

For the sake of clarity and to properly document the relationship between the sink and the DTD, it is recommended that the contentsink API be expanded to include a new pair of interfaces:

        nsresult OpenUserInterface(...);
        nsresult CloseUserInterface(...);

Document Changes

This approach assumes that the construction and maintenance of a separate UI content model. When laying out the UI, the document will iterate this model rather than the usual document content model. Note however that the UI content model will undoubtedly contain an area into which the document content model is laid out.

Note: An important step which I'm hand waving here is the binding of resources to UI elements defined in the XUI schema. I've not forgotten it, but it seems like a known art, and therefore I'm handwaving. You've been warned.

DOM Changes

While it is not strictly necessary, it would be advantagous to reflect the UI content model through the DOM. This would permit content developers to manipulate the UI in a programatic manner, much the same as they manipulate the main content model today.

Sample XUI Documents

The following examples are intended to illustrate the manner in which a UI can be described using the XUI/XML application schema. These examples are intentionally simplistic, but should provide a clear understanding the overall intention of this system. Clearly these examples do not provide evidence at this time that XUI is presently sufficient to describe an entire UI such as the Navigator.

Find Dialog

The find dialog is a non-modal window that permits a user to search the document for a run of text.

<?xml version="xml 1.0"?>
<document type="xui:dialog">
  <dialog label="Find">
    <tr>
      <td>
        Find what:
      </td>
      <td>
        <text type="edit"/>
      </td>
      <td>
        <button label="_Find Next" action="notify" listener="xxx"/>
      </td>
    </tr>
    <tr>
      <td>
        <button label="Cancel" action="close"/>
      </td>
    </tr>
    <tr>
      <td>
        <button type="checkbox" label="Match _case"/>
      </td>
    </tr>
  </dialog>
</document>

<?xml version="xml 1.0"?>
<document type="xui:app">
  <!-- describe the main menu -->
  <menubar align=top dockable=true>
    <menu type=pulldown label="_File" statusmsg="show in statusbar">
      <menuitem label="_xxx" accelerator="^X"/>
      <menuitem label="_yyy" accelerator="^Y"/>
    </menu>
    <menu type=pulldown label="_Edit" statusmsg="show in statusbar">
      <menuitem label="_xxx" accelerator="^X"/>
      <menuitem label="_yyy" accelerator="^Y"/>
    </menu>
    <menu type=pulldown label="_View" statusmsg="show in statusbar">
      <menuitem label="_xxx" accelerator="^X"/>
      <menuitem label="_yyy" accelerator="^Y"/>
    </menu>
    <menu type=pulldown label="_Go" statusmsg="show in statusbar">
      <menuitem label="_xxx" accelerator="^X"/>
      <menuitem label="_yyy" accelerator="^Y"/>
    </menu>
    <menu type=pulldown label="_Communicator" statusmsg="show in statusbar">
      <menuitem label="_xxx" accelerator="^X"/>
      <menuitem label="_yyy" accelerator="^Y"/>
    </menu>
    <menu type=pulldown label="_Help" statusmsg="show in statusbar">
      <menuitem label="_xxx" accelerator="^X"/>
      <menuitem label="_yyy" accelerator="^Y"/>
    </menu>
  </menubar>

  <!-- describe the main toolbar -->
  <toolbar label="main" align=top>
    <button type=push label="back">
      <img src="backimg"/>
      <tooltip label="backtip"/>
      <menu type=popup>
        <button label=xxx/>
        <button label=yyy/>
      </menu>
    </button>
    <button type=push label="forward">
      <img src="forwardimg"/>
      <tooltip label="forwardtip"/>
      <menu type=popup>
        <button label=xxx/>
        <button label=yyy/>
      </menu>
    </button>
    <!-- more toolbar buttons go here... -->
  </toolbar>

  <!-- describe the location bar -->
  <toolbar label="location" align=top>
  </toolbar align=top>

  <!-- describe the client area -->
  <clientarea label="clientarea"/>

  <!-- describe the status bar -->
  <statusbar label="statusbar" align=bottom>
    <text label="area1" value="your message1" border=1/>
    <text label="area2" value="your message2" border=1/>
    <text label="area3" value="your message3" border=1/>
    <toolbar label="mini">
      <button type=push label="navigator">
        <img src="nav"/>
        <tooltip label="xxx"/>
      </button>
      <button type=push label="inbox">
        <img src="xxx"/>
        <tooltip label="xxx"/>
      </button>
      <button type=push label="newsgroup">
        <img src="xxx"/>
        <tooltip label="xxx"/>
      </button>
      <button type=push label="addrbook">
        <img src="xxx"/>
        <tooltip label="xxx"/>
      </button>
      <button type=push label="composer">
        <img src="xxx"/>
        <tooltip label="xxx"/>
      </button>
    </toolbar>
  </statusbar>
</document>