There is a concept within software development known as “design patterns” where you identify specific patterns in software design and generalize them for reuse. Several such patterns have been proposed and are in common use. One well-known design pattern is called “Model-View-Controller” (MVC) where you separate the code responsible for the underlying data model, the code that presents data for the end user, and the code that modifies the data. The idea is that by keeping these parts separate it is possible to change any of these aspects without altering any of the other code. The intent when designing the XML application for the user interface language was to keep it at a high abstraction level without mixing in any programming code, to maintain a pure MVC separation, and without too many cues about how it should be rendered. This allows the user interface to be rendered into the device form factor, each device’s expected behavior, and allows for effective use of themes for design and style.

XML has proven itself to be a popular description language for representing application UI layouts. Notable examples are the layout language for Glade Interface Designer for GTK, the layout language for Android, and the XAML language for Windows Presentation Foundation from Microsoft.

Common between all these languages is the same principle that worked so well for HTML, to have nodes representing user-accessible components e.g., buttons, in a tree of layout constructs to position the component on screen or in a window. In the case of Glade/GTK, they use a small abstract language to allow for a minimal XML Schema while the other two name individual components as tags to make the language more accessible but extensibility harder. We can give similar examples from popular web frameworks like Vue and Angular, but there the line between declarative layout language and code is not as strict, which is where a lot of languages fail with respect to the Model View Control design pattern.

The idea with this project’s UI XML language is that it should be possible to create almost like a wireframe version of the UI in an XML document, then build the entire working application and at the same time have someone working on another UI XML document that makes the application look beautiful. When the designer is done, the files should be possible to swap out and the application would get a facelift.

A second dimension to this is that it should be possible to create visual themes for all the user interface components and windows, which then by the change of an attribute value of the application manifest should be possible to change and then affect the entire rendering of the application without changing any code.

The markup for the UI XML should also be as easy for someone to learn as using XHTML, this requires it to use a single implicit namespace with the addition of more namespaces only for advanced users. This creates some issues we have not fully resolved yet. The system is built so it allows for dynamic updates of the set of UI components, which in turn means the XML schema would have to be dynamically generated for anyone using this feature or the use of additional namespaces to add user developed UI components. This issue is the same as XHTML has with web components extending the language.

When creating software, there is also often a need to support multiple human languages of an application. Including all translations into the UI XML would make it hard to read and would go against the goal of separation of concerns with MVC. Instead we need an elegant mechanism to tie in translations for the currently chosen language, stored in a separate XML application for translations. The fairly non-intrusive and easy-to-use solution is using a localization namespace, using, for example, the prefix of “l”, and if then the attribute value for “title” should be translated, writing it as “l:title” instead. A transformation pass before the document is interpreted replaces all attributes in the language namespace with corresponding attributes in the default namespace, but with translated values. While it is natural to place localized data in text nodes, a drawback with this approach is that all localized data has to be in attribute values as text nodes cannot be prefixed to a namespace.

The following is a simple hello world application written in the UI XML language where the view element represents the outer boundary of the application, typically a screen or a window, the panel represents a layout container, and the button element the component to be placed inside the panel.

<view name="myView" title="My View" icon="icon://rocket">
  <panel>
    <button name="myButton" text="Hello World"/>
  </panel>
</view>

Figure 6. Rendering of the application view

The coupling of any data model or event-driven actions to the user interface is done entirely outside the UI XML in declarative XML, which means it is possible to reuse the same UI XML and even most of the program logic of an application although they work with completely different XML application documents (data models and/or data sources).

This is achieved by having every UI component like a tree, button, menu, toolbar, etc. bound directly to a fragment of an XML document where the fragment is pointed out using XPath. Events and data changes across UI components, the transaction manager, delta transactions, and the data model are all done using XML and XPath. This makes the entire event and data update bus of the Device Edge Application Server driven by XML. How the UI components should interpret the XML it is bound to are defined by the declarative data bindings. This means that UI components developed for the platform are generic and not specific or tied to any XML application, they can be reused by a software developer across all projects, as they in a simple way are taught how to understand the XML application, its hierarchy, elements, and attributes.

The following is an example of a tree UI component with rules describing how it should interpret data that it is bound to. The tree UI component is then able to render the hierarchical nodes of the tree out of the XML data model by itself. Rules can also be described in the declarative data binding for better reusability outside of the UI XML.

<view name="treeView" title="Tree Demo" icon="icon://pieces" width="250">
  <panel width="200" type="row">
    <tree name="myTree" width="100%" height="100%" icon="icon://rocket">
      <rule match="components" display="'Component List'" icon="icon://pieces" open="true"/>
      <rule match="component" display="@name" icon="icon://piece"/>
      <rule match="component/documentation" display="description" icon="icon://pencil"/>
    </tree>
  </panel>
</view>

Anyone familiar with templates in XSLT can see the similarities to how rules match underlying elements in the data model using XPath.

The final example is of the iconlist UI component that in this example is bound to the result from a container query, an Atom XML document extended to support the containers, symbolized by fs:folder elements in the feed.

<iconlist name="lists" width="100%" height="70" layout="sectionlist"
  scroll="true" deselect="false" iconsize="32">
  <rule match="fs:folder">
    <item text="{substring-after(@name, ' ')}" icon="icon://check"/>
  </rule>
</iconlist>

The rule will make sure that the iconlist component is fed one item for every fs:folder (container) that the query results in. The iconlist component is bound to the root element (atom:feed) of the Atom XML document, which means that all XPaths inside the rule is relative to this XML fragment. This is similar to how matched xsl:templates changes the current context for sub-sequent XPath expressions within the template. XPath functions are available to be used within the text attribute value, similar to how they would be used in XSLT.