User interfaces using XML

[Robert Atkey <roba dcs ed ac uk>]

Following on from a previous discussion on this list on using XML to define 
interfaces for configuration options etc I have made a XML DTD which attempts 
to cover all possible user interfaces. I know this sounds a little grand and 
pompous but the general idea is to provide a standardised way for a program to 
provide an interface without caring what it actually looks like. I have tried 
to make it as general as possible so that it could even be used for a 
text-only interface or a voice/speech interface for blind users etc. Obviously 
this would take a lot of power away from the application developer but would 
provide the ultimate in themability.

The design was made with the intention of using corba objects to implement the 
various parts of the system, like the interface manager, the 
application/program and the individual data elements (see the DTD).

Some of the inspiriation for this came from the discussion of taskets (task 
orientated widgets) form the berlin project plus the general ideas from Java's 
Swing technology. I currently have no actual code to back this up but I wanted 
to find out other people's opinion on this effort.

The DTD is attached, with lots of large comments. XML seems quite easy to 
understand.

Please tell me what you think. Some parts are pretty vague, please ask if you 
want bigger (or newly made up) explanations for them.

Bob

<!-- Document Type Definition for User Interface Markup Language -->

<!-- The basic idea behind this DTD is to provide a way to specify interfaces, 
     based on what a program needs to tell the user and what the program needs
     to know from the user -->

<!-- In this program refers to the program that the interface lays over. The
     interface manager is the program that actually deals with presenting the
     information to the user -->

<!-- All the elements, except the connect element, have a required name and 
     class attribute. The name attribute is so that the program and the 
     interface manager can refer easily to the particular element in the tree.
     The class attribute could be used with stylesheets to provide an easy way
     to present certain classes of elements (such as a help menu always being
     at the far right of a menubar). Obviously the class names would have to be
     standardised and any new ones a program introduced could be handled by a
     form of cascading stylesheets. Using an advanced stylesheet language such
     as DSSSL this could a provide 'fill-in-the-blanks' documentation template 
     for the interface -->


<!ELEMENT INTERFACE ( COMMANDGROUP, DATAGROUP, STATUSGROUP?, DIALOGUE* ) >
<!ATTLIST INTERFACE NAME CDATA #REQUIRED >
<!ATTLIST INTERFACE CLASS CDATA #REQUIRED >
<!-- This is the 'root' element of the document, it encapsulates the interface
     that the program wishes to provide to the user. It contains a command 
     group for commands that are relevant to the whole program, a datagroup 
     through which it can present it's data. Optionally a statusgroup so it 
     can provide status feedback and zero or more dialogues which are described
     below. The interface manager could interpret this as one central
     application controller plus lots of small data groups (like the gimp), 
     each with its own corba object, if corba were used -->

<!-- a group of commands -->
<!ELEMENT COMMANDGROUP ( COMMANDGROUP+ | SEMANTIC-COMMANDGROUP+ | COMMAND+ ) >
<!ATTLIST COMMANDGROUP NAME CDATA #REQUIRED >
<!ATTLIST COMMANDGROUP CLASS CDATA #REQUIRED >
<!-- This describes a set of commands all in one place, loosely related to one
     another, an example would be an item in a menu bar or a submenu -->

<!-- a group of semantically linked commands -->
<!ELEMENT SEMANTIC-COMMANDGROUP ( COMMAND )+ >
<!ATTLIST SEMANTIC-COMMANDGROUP NAME CDATA "" >
<!ATTLIST SEMANTIC-COMMANDGROUP CLASS CDATA "" >
<!-- This describes a set of commands that are more tightly related than the
     commandgroup, arguably this could be special case of the commandgroup -->

<!-- a command supported by the application, dependant on context -->
<!ELEMENT COMMAND ( CONNECT )+ >
<!ATTLIST COMMAND NAME CDATA #REQUIRED >
<!ATTLIST COMMAND CLASS CDATA #REQUIRED >
<!ATTLIST COMMAND SHORTCUTABLE ( YES | NO ) "NO" >
<!ATTLIST COMMAND SWITCH ( YES | NO ) "NO" >
<!-- this represents a particular command the program is capable of carrying
     out in its specific context, this could be a special case of the data
     element below with a 'command' interface. Shortcutable defines whether or
     not this would, say, appear on a toolbar in a GUI or have a quick command
     in a voice interface. The switch attribute defines commands that are 
     actually switches between two states or not. -->

<!-- connect a signal to a corba method in an interface -->
<!ELEMENT CONNECT EMPTY >
<!ATTLIST CONNECT SIGNAL CDATA #REQUIRED >
<!ATTLIST CONNECT MESSAGE CDATA #REQUIRED >
<!-- connects a signal emitted by the data element or the command element it
     is within to a particular part of the program. This could part of a corba
     interface or whatever -->

<!-- generic data holder -->
<!ELEMENT DATA ( CONNECT*, COMMANDGROUP* )* >
<!ATTLIST DATA INTERFACE CDATA #REQUIRED >
<!ATTLIST DATA ARGUMENTS CDATA "" >
<!ATTLIST DATA NAME CDATA #REQUIRED >
<!ATTLIST DATA CLASS CDATA #REQUIRED >
<!-- this is a generic way of describing a way of presenting data to the user.
     The interface attribute specifies a particular interface that the program
     wishes to interact with. This would fix the commands that the program can
     perform on the element and fix the signals that can be connected to using
     the connect element. The arguments more precisely specify to the interface
     what is required. If the interface manager cannot provide the required
     interface then some kind of negotiation could take place to determine the
     best interface. for example a picture viewer could ask for an interface it
     can send bitmaps to, but in a text interface this would be impossible so
     it could 'degrade gracefully' to a multi-line text interface to just print
     the size/depth etc. of the picture. An interface for single line text 
     might provide commands to change the text, insert new text, delete the
     text etc. and emit signals when the text changes or the user finishes
     (which may not necessarily be when the enter key is pressed). Enough 
     interfaces to cover everything would be hard so a scheme for combining
     them or somekind of inheritance tree system could be used
 
     The commandgroup is a group of context sensitive commands that the program
     can perform on this data -->

<!-- collections of data -->
<!ELEMENT DATACOLLECTION ( DATA+, CONNECT*, COMMANDGROUP* ) >
<!ATTLIST DATACOLLECTION INTERFACE CDATA #REQUIRED >
<!ATTLIST DATACOLLECTION NAME CDATA #REQUIRED >
<!ATTLIST DATACOLLECTION CLASS CDATA #REQUIRED >
<!-- This could represent collections of data such as lists or hierarhical
     structures. The contained data elements represent the data types held
     within the collection. This is very similar to the data element and could
     just be a special case of the data element -->

<!-- a semantically linked group of data elements -->
<!ELEMENT DATAGROUP ( ( DATA | DATACOLLECTION )+ | ( DATAGROUP )+ ) >
<!ATTLIST DATAGROUP NAME CDATA #REQUIRED >
<!ATTLIST DATAGROUP CLASS CDATA #REQUIRED >
<!-- A group of data elements, much like a command group, but for data. -->

<!-- a set of data that the application needs to carry out a command -->
<!ELEMENT DIALOGUE ( COMMANDGROUP, DATAGROUP+ ) >
<!ATTLIST DIALOGUE NAME CDATA #REQUIRED >
<!ATTLIST DIALOGUE CLASS CDATA #REQUIRED >
<!ATTLIST DIALOGUE SHORTCUTABLE ( YES | NO ) "NO" >
<!ATTLIST DIALOGUE TRANSIENT ( YES | NO ) "YES" >
<!-- In a GUI this would represent a pop up dialogue box, with the command
     group being the ok, cancel etc. buttons -->

<!-- the data that the application wishes the user to know, unobtrusively -->
<!ELEMENT STATUS ( DATAGROUP ) >
<!ATTLIST STATUS NAME CDATA #REQUIRED >
<!ATTLIST STATUS CLASS CDATA #REQUIRED >
<!-- a group of data that provides feedback to the user. The interface manager
     may only inform the user when this changes for example or just place it at
     the bottom of the window, on a floating palette or at a fixed place on the
     screen. -->