Summary of issues raised by Takashi Endo and suggested UIML 4.0 changes

["Jim Helms" <jhelms@gmail.com>]

Hello all,

Recently we have received some feedback from Mr. Takashi Endo on UIML
4.0.  Below is a summary of his issues and my suggestions on how to
address them.  I welcome any comment you have.  If everything looks
alright I will finish updating the document and send out the updated
version.

1) The id attribute is used to both declare a <variable> and to
reference it other places in the document.  This leads to an id
conflict.

Suggested change: add an attribute to <variable> called "id-ref" that
is used to reference a variable after it is declared.

2) Elements imported with templates are only given fully qualified
names when the template is sourced using "union" or "replace".  The
specification is inconsistent in describing what happens in the
"cascade" case.

Suggested change:  Make the specification consistent by assigning
fully qualified id's even in the cascade case.  Modify the definition
of conflict in the specification to indicate that the last token in
the "." delimited fully qualified ID is used to detect conflicts
instead of the whole identifier.

2.1) (Not specifically mentioned by Mr. Endo).  Uniqueness of ID's
within the document limit the usefulness of cascade.  For example, if
we want to cascade the same template onto two places in our interface
and override the same button in the template, then we would need two
buttons in the parent document with the same ID (one that would
conflict with ID of the button defined in the template).  I am not
sure what the ideal solution to this problem is, or if it is something
likely to happen in practice.  Comments are welcome.

3) Template Parameterization leads to id conflicts.

Suggested change: Kris and Jo are the experts on template
parameterization, but could this be handled using a similar mechanism
to <property>?  We could change the attribute to "name" so as not to
cause conflicts (since names are not unique).  This is how <property>
elements work.

4) The specification inconsistent uses both union and append as valid
values for the "how attribute.

Suggested change: Make "union" the accepted value for "how" and remove
"append" from the specification completely.

5) 8.3.3 Template parameterization example, Listing 10 seems to be
missing the container part.

Suggested change: Kris/Jo, can you please send me an expanded version
of the listing, or let me know that it is OK as is?

Regards,
Jim