XML UI: from XSD to XML

From the programmers perspective, obtaining data from the user via a GUI form is a pain. Usually this is solved by the creation of two functions, one to create a GUI window and populate it, and another to save the data and destroy the UI. In this ad-hoc style the schema of what is edited is never made explicit. The rules governing what data must be present and the dependencies between the various information gathered are either not coded anywhere or are a wash with the GUI style information.

This document presents the process of obtaining information from the user as a somewhat more formal one. Within this new model the application presents an XSD [XSD W3C] file detailing what a legal document will be like, and then waits for XML [XML W3C] documents that can validate to that XSD file to act on. For example, to obtain the user name and password to login to a machine an XSD document would be created containing both of these as mandatory, and then via some means (in this document Gtk+ [GTK+]) that information is prompted from the user and a valid XML document formed and passed back to the application.

The obvious advantages of this are that the programmer of the login tool does not need to worry about the style of the interface at all or its customization. Style is all handled with XSL [XSL W3C] files. The second advantage is that the collection is easily changed, for example the user may decide to always login with his mobile phone. Using this example, the computer can talk to the mobile and as for a legal XML file from a given XSD.

Also, though this document details a Gtk+2 solution the very nature of the solution presented lends itself to ncurses [NCRS], ewl [EWL] and qt [QT] solutions and stylesheets.

When the application requires information it creates an XSD file and waits for an XML file in return. There are two XSL stylesheets used. The first XSL translates an XSD file into a libglade2 XML file. The second sheet transfers a libglade2 XML file into a XML file that will validate against the original XSD file.

The steps are thus

Of these the XSL file in item ii is the most interesting. With that XSL file the user can have additional information presented in the GUI, have possibilities limited from what the XSD file allows, or have freedom to move options around in the GUI layout as he sees fit.

A look at how this XSD, XSL, XML GUI solution was applied to a real word solution is now presented.

Ferris [FerrisWebSite] is a Virtual FileSystem (VFS) looking beast. Ferris aims to allow the user to mount anything and present a tree that is both a standard n-way tree of contexts (directories and files) and also each context has another dimension for Extra Attributes (EA). Because ferris is so happy to automount things there is less of a distinction between a file and a directory, for example an XML document is both a file (when read one gets the raw XML data) and a filesystem (the logical structure of the XML document). Ferris can mount Berkeley db [Berkeley DB], XML, sockets, mysql [MySQL], ftp and mbox among others.

Due to the complexity of ferris as a VFS a solution for "creation" of new contexts was not as trivial as using a creat(2) style function in the VFS. For example in the a mysql context viewing a table, to create a new context all the non null and primary key fields of the new tuple must be present at creation time.

Initially this was handled by passing in a context to the Context::createSubContext() method. Though this was always a dirty solution because each back end module had its own expectations for what it wanted in the context passed in. The solution was passable for clients that knew a prior which context they were dealing with. There was however a need for both explicit definition of what a context needed in order to create a subcontext, and for a generic creation tool.

The formal specification of what a context needs is solved with XSD, and generic context creation is done using ferriscreate. Using XSD to formalize what a context needs to make a new subcontext also allowed a context to change what it was needing and could use for the creation. for example the native filesystem module can ask for different data (preallocation) depending on what the underlying filesystem is for that path (eg. xfs).

./configure
make
su -
make install

mkdir -p ~/.ferriscreate;
cp src/*xsl ~/.ferriscreate;

ferriscreate /tmp
ferriscreate x-sqlplus:/hostname/datebase
ferriscreate x-sqlplus:/hostname/datebase/table
ferriscreate socket:/tcp

<simpleType name="ColorSpaceT">
    <restriction base="string">
        <enumeration value="RGB"/>
        <enumeration value="Gray"/>
        <enumeration value="YUV"/>
        <enumeration value="CMYK"/>
    </restriction>
</simpleType>
<simpleType name="ColorSpaceListT">
    <list itemType="ColorSpaceT"/>
    <restriction>
        <length value="1"/>
    </restriction>
</simpleType>
	

<simpleType name="SQLDateT">
    <restriction base="string">
    </restriction>
</simpleType>
	

The ferris create example was a limited prototype that will evolve over time. There are some band aids in the example, for example the notebook labels have to be modified in C code after the GUI creation. I don't know if libglade allows setting notebook labels and at any rate I could not get any sane attempts to set the label from the libglade XML file. The solution in ferriscreate is to set the label of the notebook to the name of the first widget in that notebook. As the first widget is usually a layout widget this is a workable solution, though the path for the icon is currently set in the c++ source. The icon sought is sometimes based on the user preferences for a mime type, so interaction with ferris itself to find the name of that icon is needed. Such ferris interaction can not be done currently from either the XSL or libglade2 XML files.

To avoid some of the problems some sort of scripting language is needed in either the XSL or the libglade2 XML file itself. I am exploring the option to have a library above libglade2 that can execute scheme script from right out of the XML file. With this and a guile binding for Gtk+2 and a guile ferris binding the XSL stylesheets could be made much more powerful. For example, the contents of a entity in another XML file could be sought as the content of a gtktree.

The ferriscreate example had some limitations and was a proof of concept and as such included both the dialog running code and much of the generics right in the executable instead of as a shared library. Code that should be shared includes the dialog runner, the XML and XSL handling code, and the code to dump out the Gtk+ GUI to a libglade2 XML file again. Abstraction of this code into a shared library will be a future project.

Many of the new Gtk+2 widgets are not usable directly to the libglade XML file. Though a gtktreeview and gtktreestore may be creatable from the libglade XML file they can not be directly populated. I hope to add some new Gtk+ types to the shared dialog running library to allow more gtk+2 widgets to be directly usable from the libglade file. For example, I will be creating a gtktreestore subclass that has a property for a content-url and maybe a inline-content, this will allow the libglade to set that property from the XML directly.

Exploration of scripting from within the XML file is on the cards. Current projects such as BML [BML] are being explored for ideas in this field. While I don't think writing large applications in this style to be common, hooking up Gtk signals to effect other parts of the GUI and to call scheme code to validate data would be very handy.

Presenting a drop down list of past XML documents in the dialog would be nice. Using this the user can reuse past form data or even have bookmarks to them so that favorite XML responses can be quickly selected. This would also help ferriscreate because it could have a history list for each logical type. Thus one could make a png image like the 4th last png made.

The creation of a web based version would be interesting. Though the model is more web than desktop centric I fear that the richness that even the current limited XSD examples from ferris provide would make a web based solution require much Javascript to compete with the Gtk+ widget solution.

For discussion about this document please use the Ferris mailing list .