Proposal for Multiple <interface> and <peers> Elements

Send comments to Eric Shell (eric@g3.com)
Revised April 23, 2001

Motivation

The Document Type Definition (DTD) Appendix A of UIML2.0a specification (in www.uiml.org/specs/docs/uiml20-17Jan00.pdf) permits a document to have multiple <structure> elements. The utility of permitting multiple <structure> elements is that several alternatives can be provided in one UIML document, for example for several families of devices requiring different layouts of user interface components. The language semantics require that one of the <structure> elements are chosen when the UIML document is rendererd.Similarly, the DTD permits a UIML document to have multiple <style>, <behavior>, and <content> elements.

However, the DTD permits a UIML document to contain at most one <interface> and <peers> element. This restriction appears unnecessary. For example, multiple <peers> elements are desirable so that UIML documents can contain several differnent <peers> elements, such as one using <logic> and <presentation> elements suitable for a handheld device and another for a desktop computer. In addition, multiple <interface> elements are useful to define collaborative and multi-modal user interfaces (e.g., consisting of a voice interface in one <interface> element and a graphical interface in a second <interface> element). Thus we propose modifying the UIML DTD to permit multiple <interace> and <peers> elements.

Also, using a value of "append" for the how attribute when dealing with sources can be confusing. For example it doesn't make sense to have an element source a file using how="append" and where="first". So a more meaningful and accurate word to use would be "union".

Proposal

Change the UIML DTD in the following way. Changes have been highlighted in yellow.

    <!ELEMENT uiml (head?, template*, interface*, peers*)>

Also, everywhere there is a how attribute, change the "append" value to "union".