UIML.org: Proposals

INTRO

SPECS

TUTORIALS

RESOURCES

TOOLS

ABOUT US

CONTACT US

info@uiml.org

Proposal for Deep Cascading

Send comments to Tom Kuo (tom@harmonia.com)
revised 27 April 2001

Abstract

When using several UIML files to define a set of objects, a UIML file may source other UIML files to include any other parts that may not have been included within the set of objects in the current UIML file. That sourced file may in turn source more files for more extensions to the set of objects, thereby increasing the richness of the set of objects. Through the use of the cascade value of the attribute how, this ability to include any other parts from other external sources can be achieved.

Motivation

As the UIML vocabulary for a particular language expands and more vocabulary definitions are included in their corresponding UIML sections, templates are used to contain the vocabulary definitions in an attempt to make writing UIML easier. An example of this includes vocabulary definitions for the HTML and Java renderers. Currently templates are used to contain class definitions (e.g. <d-class> elements ) of the respective vocabulary being used. These templates can be generalized to different versions thereby categorizing each UIML template to a particular version of the target language being described (e.g. one for HTML for Internet Explorer, another for HTML for Netscape). For most target languages this means each new version release has support for previous versions of the target language, creating backwards-compatibility. For UIML this should be no different. That is as newer versions of target languages are released, the vocabulary defining that target language will need to be updated to reflect the changes. There are two ways this can be achieved. The first solution is to update every definition that was included in the old method and add whatever new methods were released. The second solution is to only define the methods that were updated or added to the new language. Old definitions that weren't changed from the previous version of the target language would be untouched and reused from older versions of the vocabulary. The second method is preferred due to its natural reusability.

Proposal

Currently an element that contains the how attribute permits three values : append, cascade, and replace. The cascade value is interpreted as taking that element and comparing that element with elements of the same type from a difference source which is specified by the preferred attribute. If that same element definition is found in both the original document and in the source document the original definition is kept over the sourced definition. This method of handling conflicting elements is preferred. However, it is the depth of which these comparisons between elements that takes place that needs to be revised. With the current specification only the top level elements in the sourced file are compared. Any children of those elements are not compared. This option proposes to interpret the how="cascade" attribute to propagate down the element for which it was specified for. That is, any children of that element (in which cascade was chosen for the value of how) could also be compared if a conflict arise between the definition of that single element. In turn, children of those first set of children could also be compared if there was a clash between the children objects. This comparisons would continue the clashed objects are resolved. The purpose of this is to compare elements from a bottom-up perspective rather than a top- down perspective. The logic behind this is justified by the way authors are expected to define element definitions. Consider the example where we want to use a set of HTML 4.0 tags that are defined in a template. In this template there are properties of the <BODY> tag that belong to the HTML 3.2 definition. These HTML 3.2 properties are shown in purple. The template we look like the one shown below.

<template name="HTML4.0">
<presentation>
    <d-class name="Html"    maps-type="tag"  maps-to="html:HTML"/>
    <d-class name="Head"   maps-type="tag"	 maps-to="html:HEAD"/>
    <d-class name="Body" maps-type="tag" maps-to="html:BODY">
         <d-property name="background"   maps-type="attribute"
         maps-to="BACKGROUND">
               <d-param type="String"/>
         </d-property>
         <d-property name="bgcolor"	maps-type="attribute"
         maps-to="BGCOLOR">
               <d-param type="String"/>
         </d-property>
         <d-property name="text"   maps-type="attribute"
         maps-to="TEXT">
               <d-param type="String"/>
         </d-property>
         <d-property name="link"   maps-type="attribute"
         maps-to="LINK">
               <d-param type="String"/>
		 </d-property>
		 <d-property name="alink"   maps-type="attribute"
         maps-to="ALINK">
		       <d-param type="String"/>
		 </d-property>
		 <d-property name="vlink"   maps-type="attribute"
         maps-to="VLINK">
		       <d-param type="String"/>
		 </d-property>
		 <d-property name="class"   maps-type="attribute"
         maps-to="CLASS">
		       <d-param type="String"/>
		 </d-property>
		 <d-property name="id"   maps-type="attribute"
         maps-to="ID">
		       <d-param type="String"/>
		 </d-property>
		 <d-property name="lang"   maps-type="attribute"
         maps-to="LANG">
		       <d-param type="String"/>
		 </d-property> 
		 <d-property name="style"   maps-type="attribute"
         maps-to="STYLE">
		       <d-param type="String"/>
		 </d-property>
		 <event class="onLoad"/>
		 <event class="onunLoad"/>
		 <event class="onBlur"/>
		 <event class="onFocus"/> 
	</d-class> 
    .
    .
    .
</template>

The problem with the template above is that it doesn't allow for any flexibility. In the example above the template mixes definitions of properties and classes from HTML 4.0 and HTML 3.2. This can create quite a hassle when updating a vocabulary definitions to include new classes and/or updating older class definitions, because each tag would have to be redefined in another template. An easier solution is to have one set of vocabulary definitions that are specific to that particular version of the vocabulary each in a separate template file. Newer versions would then source previous versions which that template itself may source previous versions and so on. Using the example above, we would split the first template into to templates as shown below.

<Template name="HTML3.2">
<presentation how="cascade" source="HTML3_2_v00.uiml#HTML3.2">
        <d-class name="Body" maps-type="tag" maps-to="html:BODY">
		 <d-property name="class"   maps-type="attribute"
         maps-to="CLASS">
		       <d-param type="String"/>
		 </d-property>
		 <d-property name="id"   maps-type="attribute"
         maps-to="ID">
		       <d-param type="String"/>
		 </d-property>
		 <d-property name="Lang"   maps-type="attribute"
         maps-to="LANG">
		       <d-param type="String"/>
		 </d-property> 
		 <d-property name="style"   maps-type="attribute"
         maps-to="STYLE">
		       <d-param type="String"/>
		 </d-property>
		 <event class="onLoad"/>
		 <event class="onunLoad"/>
		 <event class="onBlur"/>
		 <event class="onFocus"/> 
	</d-class>
    .
    .
    .
</template>

<template name="HTML3.2">
<presentation>
    <d-class name="Html"  maps-type="tag"  maps-to="html:HTML"/>
    <d-class name="Head"  maps-type="tag"	 maps-to="html:HEAD"/>
    <d-class name="Body" maps-type="tag" maps-to="html:BODY">
         <d-property name="background"   maps-type="attribute"
         maps-to="BACKGROUND">
               <d-param type="String"/>
         </d-property>
         <d-property name="bgcolor"	maps-type="attribute"
         maps-to="BGCOLOR">
               <d-param type="String"/>
         </d-property>
         <d-property name="text"   maps-type="attribute"
         maps-to="TEXT">
               <d-param type="String"/>
         </d-property>
         <d-property name="link"   maps-type="attribute"
         maps-to="LINK">
               <d-param type="String"/>
		 </d-property>
		 <d-property name="alink"   maps-type="attribute"
         maps-to="ALINK">
		       <d-param type="String"/>
		 </d-property>
		 <d-property name="vlink"   maps-type="attribute"
         maps-to="VLINK">
		       <d-param type="String"/>
		 </d-property>
	</d-class>
    .
    .
    .
</template>

A couple things to notice with the two templates. First notice that template named="HTML4.0" sources the HTML3.2 template. Second notice that the Body class in each template define different properties for the same class. Because there are no conflicts between the properties of each class, the set of properties from the older definition (in this case the HTML 3.2 template) will be "merged" with the definitions from the HTML 4.0 template. Also note the Head and Html classes are not defined in the HTML 4.0 template because those classes are already defined in the HTML 3.2 template and do not need to be "redefined". This splitting of vocabulary definitions of distinct sets into multiple templates can allow more flexibility in not only defining and updating a language's vocabulary, but also allows more flexibility in choosing a particular set of vocabulary definitions over another.

Implementation Considerations

While doing a deep cascade, in the event that an element where the DTD does not allow the source attribute is reached, then the depth-wise cascading in that branch ends at that element. Any child elements of that element that does not allow the source attribute, will not be compared during cascading.