Send comments to Cara Struble (cara@harmonia.com)
Authors: Marc Abrams and Cara Struble
23 May 2001

Note: The revisions made to this document in April 2001 introduced one new UIML tag, <listener>. Also the use of
<d-event> was deleted, the <d-class> tag was modified to allow <d-method> as its child,and the class attribute in <event> when a listener is used was changed to use a dotted notation. These changes result from Harmonia's experience in creating a full <presentation> element for Java AWT and Swing, and using that element to initialize its Java renderer.

Why Is a Revision Needed?

There are several deficiencies in past UIML2 DTDs, up to UIML2_0d.dtd:

• No attempt had ever been made before to define the <presentation> section for any platform. Doing so for Java AWT/Swing, WML, VoiceXML, and HTML uncovered several weaknesses:
• A richer syntax was needed to fully define peers for events (discussed below).
• There was no way to define events and event listeners for Java.
• There old syntax treated all properties as having methods to set and get; this is not natural way to describe a mapping of a class to a markup language tag.

• The <attribute> tag was misleading. The tag was defining a name to be used in a <property>, so why call it <attribute>?

• The old syntax treated both presentation peers and logic peers as <component>. When the UIML2 spec was first written, this seemed like an elegant way to do things. But there are two reasons why presentation peers (either for parts or for events) should be called something else:
• The <presentation> element is defining what someClass means in class="someClass". The <logic> element is defining what whoToCall means in <call name="whoToCall">. So it makes sense to have two components: <component> and <class>.
• A <presentation> peer can be mapped to an attribute name from a markup language. A markup language really doesn’t have a notion of doing "operations" like set and get on an attribute. So it doesn’t really make sense for the body of <presentation> to contain <method> tags.

• The <mparam> tag has always had a strange name. The "m" in "mparam" was used to distinguish the tag from the <param> tag. (<param> is an actual parameter to a <call>, and <mparam> is a formal parameter.)

• The UIML2_0c.dtd <method> element allowed a type (e.g., "int") to be optionally specified for method parameters via the <mparam> element’s type attribute. In contrast, for methods that return a value, you could only say whether the method had a return value or not (via the returns-value attribute of element <method>), but you could not specify the type of the return value. It seems wise to allow the type of the return value to be specified (by introducing an attribute return-type to <method>, to replace returns-value.

There are two styles of events used by platforms:

• Method 1: A <part> defines how events for it are handled.
• Method 2: A <part>does not define how events for it are handled.

Method 2 is used in Java 1.1 and later. We adopt the Java model of requiring a Listener entity that defines how events are handled on behalf of a <part>. (If there exists a target language for UIML that uses Method 2 and also uses a concept entirely different than listeners, then UIML will need modification.) In this case, a Listener class defines how events are handled. In UIML, the association between the event mouseClicked and the actions to perform in response is made by a <rule>. The UIML user is not aware of the Listener or Event classes involved.

Thus UIML must contain a rich enough syntax to define the following:

• Class names representing events (such as "OnClick" for HTML, or "MouseEvent" for Java)
• Event property names (such as "X" and "Y" coordinates for a MouseEvent)
• Class names representing event listeners for Method 2 (such as MouseListener)
• Methods in event listeners (such as MouseListener.mouseClicked())
• A means to associate components, listeners, and events.

New <d-…> Syntax

Earlier we referred to the <mparam> tag as having a strange name. What should we call it? Also, earlier we said that <attribute> was a silly tag because it defined a property (and could be confused for an attribute of a markup language tag). What should it be renamed?

The proposed answer is to use these names:

Now once we have introduced "d-", it makes sense to ask whether it should be used in any construct that is declaring or defining something used elsewhere. This leads us to changing <component> to <d-component> (since the element makes a component declaration). We also propose changing <method> to <d-method>, since the body is giving the declaration of a method prototype. And of course we’ll use <d-class> (to define a class) instead of using <class>. Every class attribute that appears in any UIML element is defined by a <d-class> element.

We also stated that there must be a construct in UIML to associate listeners with components for event method 2 above. Hence we propose adding to UIML a new tag, <listener>.

Summary of Syntax to Define Events and Listeners

For HTML:

Shown below is a skeleton of a <presentation> element for mapping UIML to HTML:

<presentation name="HTML">

  <d-class name="OnClick" used-in-tag="event" .../>

  <d-class name="Button" used-in-tag="part" .../>
    <event name="OnClick">
  </d-class>

</presentation>

The above UIML says that one of the events in HTML is OnClick, and that a <part> whose class is Button can receive an OnClick event.

For Java/Swing:

Shown below is a skeleton of a <presentation> element for mapping UIML to Java AWT/Swing:

<presentation name="AWT-Swing">

  <d-class    name="ActionEvent" used-in-tag="event" ...>
    <d-method name="actionCommand" ...>
  </d-class>

  <d-class     name="ActionListener"  used-in-tag="listener" ...>
    <d-method  name="actionPerformed" ...>
      <d-param type="ActionEvent"/>
    </d-method>
  </d-class>

  <d-class    name="JButton" used-in-tag="part" .../>
    <listener class="ActionListener" ...>
  </d-class>

</presentation>

The above UIML says that one of the events in Java AWT/Swing is ActionEvent, one of the listeners is ActionListener, ActionListener has a method named actionPerformed that processes ActionEvents, and that events for a <part> whose class is JButton are handled by a listener named ActionListener.

Detailed Example for HTML <presentation>

Shown below is a fragment of a <presentation> element for mapping UIML to HTML. The single HTML tag

<presentation name="HTML"> 

  <!--    ========== Define event classes ==================== -->  

  <d-class name="onClick" used-in-tag="event"
                          maps-type="attribute"
                          maps-to="onClick"/> 

  <!--    ========== Define part classes ===================== -->  

  <d-class name="Button" used-in-tag="part"
                         maps-type="tag"
                         maps-to="html:INPUT"> 

    <!--    ======== Define properties of part class Button == -->  

    <d-property name="type" maps-type="attribute" maps-to="NAME">
      <d-param type="String">BUTTON</d-param>
    </d-property>  

    <d-property name="value" maps-type="attribute" maps-to="VALUE"> 
      <d-param type="String"/> 
    </d-property> 

    <!--    ======== List which events are valid for part class JButton -->  

    <event class="onClick"/>  

  </d-class> 

</presentation> 

The above fragment illustrates that for each element in the target platform that should be a UIML class, you need to specify four things:

1. What are the class names that are used in the <event class="…"> element? This is answered by the red text above (<d-class used-in-tag="event"> element). Here we see that there is one event, called "onClick". The used-in-tag says that this class name (OnClick) must be referenced in an <event> tag. The maps-type attribute says that this event is represented by an attribute in a markup language (as opposed to a tag). Note that the red text defining event class names is outside the definition of any <part> classes. That’s because many classes, not just Button, use the onClick event.
2. What are the class names that are used in the <part class="…"> element? This is answered by the purple text above (<d-class used-in-tag="part"> element). Here we see that there is one class being defined, called "Button", and it maps to the HTML tag <input>.
3. What are the property names that are used in the <property name="…"> element for a particular part class? This is answered in the green text above (the two <d-property> elements). Here we see that there is one property being defined, value. It maps to the VALUE attribute of the <input> tag (thus to <input VALUE="…"/>).
   
4. What event classes (from the red text) can be used with the <part> class of the parent element (the purple text)? This is answered by the orange text (the event tag). Here we see that there is one event possible, onClick.

When writing rules, the class attribute of an event element in a condition can be any of the names listed in an <event> element that is associated with the <part> in the <presentation> section. In the above example, a Button's events include OnClick. This is illustrated by the following example:

<rule>
  <condition>
    <event class="OnClick" part="MyButton">
  </condition>
  <action>
    ...
  </action>
</rule>

Shown below is a fragment of a <presentation> element for mapping UIML to Java. A Swing JButton is considered.

<presentation name="AWT-Swing"> 

  <!-- ==================== Define event classes ==================== --> 

  <d-class    name="MouseEvent"     used-in-tag="event"
                                    maps-type="class"
                                    maps-to="java.awt.event.MouseEvent">
    <d-method name="source"         maps-to="getSource" 
                                    return-type="java.lang.Object"/>
    <d-method name="id"             maps-to="getId" 
                                    return-type="int"/> 
    <d-method name="clickCount"     maps-to="getClickCount"    
                                    return-type="int"/> 
    <d-method name="point"          maps-to="getPoint" 
                                    return-type="java.awt.Point"/> 
    <d-method name="X"              maps-to="getX" 
                                    return-type="int"/> 
    <d-method name="Y"              maps-to="getY" 
                                    return-type="int"/> 
    <d-method name="isPopupTrigger" maps-to="getIsPopupTrigger"    
                                    return-type="boolean"/>
  </d-class> 

  ... 

  <!-- ==================== Define event listener classes ============ --> 

  <d-class   name="MouseListener"    used-in-tag="listener"
                                     maps-type="class"
                                     maps-to="java.awt.event.MouseListener">
    <d-method name="mouseClicked"    maps-to="mouseClicked"> 
      <d-param  name="event"         type="MouseEvent"/> 
    </d-method> 

    <d-method name="mouseEntered"    maps-to="mouseEntered"> 
      <d-param  name="event"         type="MouseEvent"/> 
    </d-method> 

    <d-method name="mouseExited"     maps-to="mouseExited"> 
      <d-param  name="event"         type="MouseEvent"/> 
    </d-method> 

    <d-method name="mousePressed"    maps-to="mousePressed"> 
      <d-param  name="event"         type="MouseEvent"/> 
    </d-method> 

    <d-method name="mouseReleased"   maps-to="mouseReleased"> 
      <d-param  name="event"         type="MouseEvent"/> 
    </d-method> 

  </d-class>

  ...

  <!-- ==================== Define part classes ==================== --> 

  <d-class name="JButton" used-in-tag="part" 
                          maps-type="class"
                          maps-to="javax.swing.JButton"> 

    <!-- =========== Define properties of part class JButton == = -->    

    <d-property  name="text" maps-type="setMethod"
                             maps-to="setText">     
      <d-param               type="java.lang.String"/>
    </d-property>

    <d-property name="text"     return-type="java.lang.String"
                                maps-type="getMethod"
                                maps-to="getText"/>   
    </d-property>    

    <d-property name="size"     maps-type="setMethod"
                                maps-to="setSize">      
      <d-param  name="width"    type="int"/> 
      <d-param  name="height"   type="int"/> 
    </d-property>    

    ...    

    <!-- ====== List which events are valid for part class JButton === -->    

    <listener class="ActionListener"          attacher="addActionListener"/>
    <listener class="AncestorListener"        attacher="addAncestorListener"/> 
    <listener class="ChangeListener"          attacher="addChangeListener" /> 
    <listener class="ComponentListener"       attacher="addComponentListener"/> 
    <listener class="ContainerListener"       attacher="addContainerListener"/> 
    <listener class="FocusListener"           attacher="addFocusListener" /> 
    <listener class="HierarchyListener"       attacher="addHeirarchyListener"/> 
    <listener class="HierarchyBoundsListener" attacher="addHeirarchyBoundsListener"/>      
    <listener class="InputMethodListener"     attacher="addInputMethodListener"/> 
    <listener class="ItemListener"            attacher="addItemListener"/> 
    <listener class="KeyListener"             attacher="addKeyListener"/> 
    <listener class="MouseListener"           attacher="addMouseListener"/> 
    <listener class="MouseMotionListener"     attacher="addMouseMotionListener"/> 

  </d-class>

</presentation> 

Comparing the above fragment to the HTML example, there are these differences:

• The first part of the example, with red text, uses the <d-class used-in-tag="event"> element to define events. This part differs from the HTML example above in that events have methods to retrieve information about the event. For example, a MouseEvent has methods to retrieve the X and Y coordinate of the mouse position.
  
  
• The second part, with brown text, uses the <d-class used-in-tag="listener"> element to define all possible listeners. This part is not present in the HTML example earlier, because the HTML event model ("Method 1") does not use listeners. Note that the brown text defining event listeners is outside the definition of any <part> classes. That’s because many classes, not just JButton, use listeners.

• The green text (the <d-property> elements) differs from the earlier HTML example because <part> properties map to Java set/get methods (as opposed to HTML tag attributes).
  
  The green text could also contain <d-method> elements. This is useful for exposing in UIML methods in the Java class that are not properties (and hence should not be accessed in the UIML <property> elements), but still should be callable in UIML. For example, java.awt.List contains a method add(...) to add another item to a list. An <action> in a UIML document might contain a <call> to the add method.

• The orange text above (the <listener> elements) is nested inside the class definition for a JButton. The orange text enumerates which listeners are used for a JButton. In addition, the <listener> element includes an "attacher" attribute that names the method that the JButton uses to attach the listener to itself. For example, the UIML above says that JButton has a method called "addMouseListener" that is used to attach a MouseListener to a JButton.

When writing rules, the class attribute of an event element in a condition uses a dotted notation consisting of the form <listener class name>.<method class name>. The <listener class name> is a class name defined by a <d-class used-in-tag="listener"> element, such as MouseListener in the UIML example above. The <method class name> is a method name defined in a <d-method> element that is a child of the <d-class used-in-tag="listener"> element, such as mouseClicked in the UIML above. This is illustrated by the following example:

<rule>
  <condition>
    <event class="MouseListener.mouseClicked" part="MyButton">
  </condition>
  <action>
    ...
  </action>
</rule>

Example of <logic> Element

So far, we’ve discussed the <presentation> element. We’ve proposed changes such as renaming <component> to <d-component>. Here is an example, from examples\EventsAndCalls\EventCounter2.uiml in the UIML Java Renderer distribution uiml2jr-0.4a.zip posted on www.harmonia.com.

<logic>
 <d-component name="Counter" maps-to="com.universalit.example.Counter2">
   <d-method name="count" return-type="int" maps-to="count"/>
   <d-method name="reset" return-type="int" maps-to="setCount">
     <d-param name="newVal" type="int"/>
   </d-method>
 </d-component>
</logic>

The fragment above says that there is an external object reached by name com.universalit.example.Counter2. This object is given the name Counter in the UIML document. The components has two methods, named count and reset in the UIML document. These map, respectively, to count and setCount in com.universalit.example.Counter2. Each returns a value of type int, where the meaning of int is whatever meaning ascribed by the language in which com.universalit.example.Counter2 is implemented. Finally, count takes no arguments when called, and setCount takes one argument, an int.
 

Summary of Proposed Changes

• Added new element: "d-class"
• Added new element: "listener"
• Renamed element "attribute" to "d-property"
• Renamed element "component" to "d-component"
• Renamed element "method" to "d-method"
• Renamed element "mparam" to "d-param"
• Renamed attribute "returns-value" to "return-type", and made value #IMPLIED to represent a return type
• Added "d-class" as child of element "presentation"
• Added "d-param" as child of element "d-property" (formerly "attribute")
• Dropped "attribute" as child of element "d-component" (formerly "component")

Following is the proposal for the revised DTD.

<?xml version="1.0" encoding="ISO-8859-1"?> 

<!-- ==================== Content Models ======================= --> 

<!-- 
'uiml' is the root element of a UIML document. 
--> 

<!ELEMENT uiml (head?, template*, interface?, peers?)> 

<!-- 
    The 'head' element is meant to contain metadata about the UIML 
    document. You can specify metadata using the meta tag, 
    this is similar to the head/meta from HTML. 
--> 

<!ELEMENT head (meta)*> 
<!ELEMENT meta EMPTY> 
<!ATTLIST meta 
          name NMTOKEN #REQUIRED 
          content CDATA #REQUIRED> 

<!-- 
    The 'peers' element contains information that defines 
    how a UIML interface component is mapped to the target platform's 
    rendering technology and to the backend logic. 
--> 

<!ELEMENT peers (presentation|logic)*> 
<!ATTLIST peers 
          name NMTOKEN #IMPLIED 
          source CDATA #IMPLIED 
          how (append|cascade|replace) "replace" 
          export (hidden|optional|required) "optional"> 

<!-- 
    The 'interface' element describes a user interface in terms of 
    presentation widgets, component structure and behavior specifications. 
--> 

<!ELEMENT interface (structure|style|content|behavior)*> 
<!ATTLIST interface 
          name NMTOKEN #IMPLIED 
          source CDATA #IMPLIED 
          how (append|cascade|replace) "replace" 
          export (hidden|optional|required) "optional"> 

<!-- 
    The 'template' element enables reuse of UIML elements. 
    When an element appears inside a template element it can 
    sourced by another element with the same tag. 
--> 

<!ELEMENT template (behavior|constant|content|d-class|d-component|interface 
                   |logic|part|peers|presentation|property|rule 
                   |script|structure|style)> 
<!ATTLIST template 
          name NMTOKEN #IMPLIED> 

<!-- Peer related elements --> 

<!-- 
    The 'presentation' element specifies the mapping between 
    abstract interface parts and platform dependent widgets. 
--> 

<!ELEMENT presentation (d-class|d-component)*> 
<!ATTLIST presentation 
          name NMTOKEN #IMPLIED 
          source CDATA #IMPLIED 
          how (append|cascade|replace) "replace" 
          export (hidden|optional|required) "optional"> 

<!-- 
    The 'logic' element specifies the connection between the interface 
    and the backend application, including support for scripting. 
--> 

<!ELEMENT logic (d-component*)> 
<!ATTLIST logic 
          name NMTOKEN #IMPLIED 
          source CDATA #IMPLIED 
          how (append|cascade|replace) "replace" 
          export (hidden|optional|required) "optional"> 

<!-- 
    The 'd-component' element declares the interface to logic components in the backend 
    (e.g., a class in an object oriented language or a function in a scripting langauge) 
--> 

<!ELEMENT d-component (d-method)*> 
<!ATTLIST d-component 
          name NMTOKEN #REQUIRED 
          source CDATA #IMPLIED 
          how (append|cascade|replace) "replace" 
          export (hidden|optional|required) "optional" 
          maps-to CDATA #REQUIRED 
          location CDATA #IMPLIED> 

<!--    
          The 'd-class' element declares any name used in the "class"
          attribute of any element in UIML.
--> 

<!ELEMENT d-class (d-method*, d-property*, event*, listener*)> 
<!ATTLIST d-class 
          name NMTOKEN                         #REQUIRED 
          source CDATA                         #IMPLIED 
          how (append|cascade|replace)         "replace" 
          export (hidden|optional|required)    "optional" 
          used-in-tag (event|listener|part)    #REQUIRED
          maps-type (tag|class)                #REQUIRED 
          maps-to CDATA                        #REQUIRED> 

<!--    
          The 'd-property' element associates a specific property with the    
          methods that set and get its value. 
--> 

<!ELEMENT d-property (d-method*, d-param*)> 
<!ATTLIST d-property 
          name NMTOKEN #REQUIRED 
          maps-type (attribute|getMethod|setMethod) #REQUIRED 
          maps-to CDATA #REQUIRED 
          return-type CDATA #IMPLIED> 

<!-- 
    The 'method' element describes a routine that forms part 
    of a component's callable interface (i.e., the component's "API"). 
--> 

<!ELEMENT d-method (d-param*, script?)> 
<!ATTLIST d-method 
          name NMTOKEN #REQUIRED 
          source CDATA #IMPLIED 
          how (append|cascade|replace) "replace" 
          export (hidden|optional|required) "optional" 
          maps-to CDATA #REQUIRED 
          return-type CDATA #IMPLIED> 

<!-- 
    'd-param' denotes either a single formal parameter to a callable 
    routine or attribute in a markup language 
--> 

<!ELEMENT d-param (CDATA)?> 
<!ATTLIST d-param 
          name NMTOKEN #IMPLIED 
          type CDATA #IMPLIED> 

<!-- 
    The 'script' element contains data passed to an embedded scripting 
    engine. The type specifies the scripting language (see HTML4.0) 
--> 

<!ELEMENT script (#PCDATA)> 
<!ATTLIST script 
          name NMTOKEN #IMPLIED 
          type NMTOKEN #IMPLIED 
          source CDATA #IMPLIED 
          how (append|cascade|replace) "replace" 
          export (hidden|optional|required) "optional"> 
  

<!-- Interface related elements --> 

<!-- 
    The 'structure' element describes the initial logical relationships 
    between the components (i.e., the "part"s) that comprise the user 
    interface. 
--> 

<!ELEMENT structure (part*)> 
<!ATTLIST structure 
          name NMTOKEN #IMPLIED 
          source CDATA #IMPLIED 
          how (append|cascade|replace) "replace" 
          export (hidden|optional|required) "optional"> 

<!-- 
    A 'part' element describes a conceptually complete component of the 
    user interface. 
--> 

<!ELEMENT part (style?, content?, behavior?, part*)> 
<!ATTLIST part 
          name NMTOKEN #IMPLIED 
          class NMTOKEN #IMPLIED 
          source CDATA #IMPLIED 
          how (append|cascade|replace) "replace" 
          export (hidden|optional|required) "optional"> 

<!-- 
    A 'style' element is composed of one or more 'property' elements, 
    each of which specifies how a particular aspect of an interface 
    component's presentation is to be presented. 
--> 

<!ELEMENT style (property*)> 
<!ATTLIST style 
          name NMTOKEN #IMPLIED 
          source CDATA #IMPLIED 
          how (append|cascade|replace) "replace" 
          export (hidden|optional|required) "optional"> 

<!-- 
    A 'property' element is typically used to set a specified 
    property for some interface component (or alternatively, 
    a class of interface components), using the element's 
    character data content as the value. If the 'operation' 
    attribute is given as "get", the element is equivalent to 
    a property-get operation, the value of which may be "returned" 
    as the content for an enclosing 'property' element. 
--> 

<!ELEMENT property (#PCDATA|constant|property|reference|call)*> 
<!ATTLIST property 
          name NMTOKEN #IMPLIED 
          source CDATA #IMPLIED 
          how (append|cascade|replace) "replace" 
          export (hidden|optional|required) "optional" 
          part-name NMTOKEN #IMPLIED 
          part-class NMTOKEN #IMPLIED 
          event-name NMTOKEN #IMPLIED 
          event-class NMTOKEN #IMPLIED 
          call-name NMTOKEN #IMPLIED 
          call-class NMTOKEN #IMPLIED> 

<!-- 
    A 'reference' may be thought of as a property-get operation, 
    where the "property" to be read is a 'constant' element defined 
    in the UIML document's 'content' section. 
--> 

<!ELEMENT reference EMPTY> 
<!ATTLIST reference 
          constant-name NMTOKEN #REQUIRED> 

<!-- 
    The 'content' element is composed of one or more 'constant' 
    elements, each of which specifies some fixed value. 
--> 

<!ELEMENT content (constant*)> 
<!ATTLIST content 
          name NMTOKEN #IMPLIED 
          source CDATA #IMPLIED 
          how (append|cascade|replace) "replace" 
          export (hidden|optional|required) "optional"> 

<!-- 
    'constant' elements may be hierarchically structured. 
--> 

<!ELEMENT constant (constant*)> 
<!ATTLIST constant 
          name NMTOKEN #IMPLIED 
          source CDATA #IMPLIED 
          how (append|cascade|replace) "replace" 
          export (hidden|optional|required) "optional" 
          model CDATA #IMPLIED 
          value CDATA #IMPLIED> 

<!-- 
    The 'behavior' element gives one or more "rule"s that 
    specifies what 'action' is to be taken whenever an associated 
    'condition' becomes TRUE. 
--> 

<!ELEMENT behavior (rule*)> 
<!ATTLIST behavior 
          name NMTOKEN #IMPLIED 
          source CDATA #IMPLIED 
          how (append|cascade|replace) "replace" 
          export (hidden|optional|required) "optional"> 
  

<!ELEMENT rule (condition,action)?> 
<!ATTLIST rule 
          name NMTOKEN #IMPLIED 
          source CDATA #IMPLIED 
          how (append|cascade|replace) "replace" 
          export (hidden|optional|required) "optional"> 

<!-- 
    At the moment, "rule"s may be associated with two types of 
    conditions: (1) whenever some expression is equal to some other 
    expression; and (2) whenever some event is triggered and caught. 
--> 

<!ELEMENT condition (equal|event)> 

<!ELEMENT equal (event,(constant|property|reference))> 

<!ELEMENT action ((property|call)*, event?)> 

<!ELEMENT call (param*)> 
<!ATTLIST call 
          name NMTOKEN #IMPLIED 
          class NMTOKEN #IMPLIED> 

<!--
   'event' denotes one of two things:
   (1) Inside <condition>, denotes that when the named event is fired,
   the condition should be evaluated.
   (2) Inside <d-class>, denotes that the named event can occur for
   the part class named by the <d-class>.
-->

<!ELEMENT event    EMPTY> 
   <!ATTLIST event    
                name NMTOKEN #IMPLIED 
                class NMTOKEN #IMPLIED 
                part-name NMTOKEN #IMPLIED 
                part-class NMTOKEN #IMPLIED>  

<!-- 
    'param' denotes a single actual parameter to a call-able routine. 
--> 

<!ELEMENT param    (#PCDATA|property|reference|call)*> 
   <!ATTLIST param    
                name NMTOKEN #IMPLIED>  

<!--
   'listener' denotes that a name defined with d-class
    used-in-tag="listener" should be attached as a listener to the
    d-class which contains this <listener> element.
   -->

<!ELEMENT listener EMPTY>
<!ATTLIST listener
   class    NMTOKEN #IMPLIED
   attacher CDATA   #IMPLIED> 

© 1999-2000 UIML.org (all rights reserved)