Re: [uiml] Summary of issues raised by Takashi Endo and suggested UIML 4.0 changes

["Robbie Schaefer" <robbie@c-lab.de>]

Dear Jim and all,

> Recently we have received some feedback from Mr. Takashi Endo on UIML

Yes, this kind of feedback is really helpful.

> 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.

We had thought of this when designing DISL and the current sulution in the 
UIML-DTD is that we have an additional attribute for the variable which 
specifies wether it is used as a declaration or as a reference: reference 
(true|false) "true".

However if all agree that id-ref is the more proper/consitent solution 
(since it is used in other UIML-elements in the same fashion) I could go 
through the relevant parts in the spec and change the examples and 
explanations.

The point in favor of the "reference"-Attribute is that it is implicitly set 
true, so that only once, for the declaration, a variable needs to state the 
reference attribute, which IMHO adds to the readability of the 
UIML-document.

Anyway, I am open to both options.

All the best,
Robbie.
--
   _/ Dr. Robbie Schaefer        _/ Phone: +49 5251 60-6107  _/
  _/ Visual Interactive Systems _/ Fax: +49 5251 60-6065    _/
 _/ C-LAB Fuerstenallee 11     _/                          _/
_/ D-33102 Paderborn          _/ URL: http://www.c-lab.de _/

----- Original Message ----- 
From: "Jim Helms" <jhelms@gmail.com>
To: <uiml@lists.oasis-open.org>
Sent: Sunday, December 02, 2007 8:53 PM
Subject: [uiml] Summary of issues raised by Takashi Endo and suggested UIML 
4.0 changes


> This should have gone out to the regular list as well.
>
> ==========================================================================
>
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in 
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>