Uiml 3.0 notes

Personal notes on the UIML3.0 specification

Goal

Errors in the 3.0 spec

• On page 55, the second line of 5.7.5.1: "these types pf events" should say "these types of events" of course.
• I noticed the following line '<presentation name="xxxxxxx">' on pages 16 and 17. If you look at the DTD and the description of the presentation element on page 72, "name" is not defined as an attribute.
• On page 16 there is a small example of the peers element, using "component" and "attribute" as children of the "presentation" element. These two elements are not defined in the DTD, or in the list on page 26. I think this should be "d-class" and "d-property" instead of "component" and "attribute"?
• on page 88 there is an example of the d-property element. This example contains a d-component element as a child of a presentation tag. The DTD does not allow this, and I assume it should have been the d-class element instead of the d-component element.
• The definition for constant contains an attribute model. This attribute is not explained in the specification. There is only one example (Dictionary.ui) in the specification using it. I guess the model attribute refers to the type of the constant data.
• On page 78 there is a small error in an example: <style><property name= VALUE>Press me!</property></style>. VALUE should be lowercase! (otherwise the style definition is wrong)
• On page 58 the name attribute of the call element is defined as "#IMPLIED", I think this should be "#REQUIRED". In contradiction with the DTD, the "class" attribute is also missing in the definition of the call element.
• On page 38 there is an example at the bottom with the elements "Pre" and "P" which are not defined in the DTD. Probably, there two elements should be "part" elements.

Difficulties while implementing

• The spec says little about layout. Nevertheless this is a major problem for getting into the spec when targetting different devices with non-uniform screen spaces. Most resources discussing UIML and mentioning layout refer (or ``postpone'') this problem as one of the actual design of the UI. We used spatial constraints in Dygimes to solve this problem.
• The relation between application logic and interface is not completely clear in the specification. There is no uniform way of ``connecting'' to the interface: this way on-the-fly interface migration is not supported very well. Maybe it should define standard ``links'' to the application logic, and restrict the UI designer to a basic set of operations.
• If you want to keep the ``concrete widget creation'' core of the program as type-independent and dynamic as possible, a reflection mechanism is your friend! It is even easier when having widget constructors without arguments, so the properties can be set iteratively on a ``clean'' widget object. One possibility is to iterate over the constructors and see which arguments match the properties defined in the style tree. If there are matches in argument names/types and property name/types these can be set using the constructor. This is done in the UIML.net renderer: See the gtk-sharp vocabulary in the examples directory. Unfortunately it requires a non-conformant implementation of the spec. I extend the possible values of the maps-type attribute of the d-property element: (attribute|getMethod|setMethod|method|constructor)
• Gtk.Label has no parameterless constructor. This kind of widgets makes it difficult use a generic way for the widget creation in the renderer. See the remark above for a possible solution.
• The specification only allows to set single string values as properties: allowing combined content with structured values is easier to map on a concrete widget set. Redefining how nested properties work is necessary (e.g. sub-properties deliver structured content to their parent properties). The spec should be more clear about the content of d-property. Maybe the model element can help out here?
• The call-element allows to invoke a funtionality of the program logic. In a certain way, describing the UI using XML means choosing a declarative way of building the UI (instead of a procedural way). So it is difficult or not natural to have actual (variables/) objects to invoke some functionality on. When static methods are called, only the Type of the object is necessary. When a non-static method has to be called, where does one get the actual object reference? Also, the name attribute forces to do some string parsing to identify which part is the method name and which part is the object name. This is a limitation for writing a renderer dealing with different program languages or different types of method invocation: it limits reusability.
• The constant-element is structured strange. The content element can only be a parent of a constant element when it is child of a part. If constant is used inside a property, there is no content element surrounding it. I think the content element inside a part element should be explained in a clear way in the spec, using some examples.

Misc.

• Probably languages making use of a Virtual Machine (thus offering extensive reflection capabilities and dynamic loading of new code) are better suited to be used for implementing a Uiml Renderer. Languages like Java, C# or Python are easier to use. When the vocabulary defines mappings using the exact class name, these languages can dynamically load the widget and use it further on. Dygimes also made extensive use of the reflection and dynamic loading capabilities of the Java Virtual Machine.
• Should port TaskLib to C# and integrate Uiml with it. This allows to render and compose the dialogs of a UI starting from the Task Model.

Menu