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

["Jo Vermeulen" <jo.vermeulen@uhasselt.be>]

On Dec 2, 2007 8:49 PM, Jim Helms <jhelms@gmail.com> wrote:

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


Maybe it is better to keep it consistent with properties and
template-parameters, and just use "name"?


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


Indeed, that's something we forgot. Certainly a useful comment by Mr.
Takashi Endo! I agree we should be consistent here, and use "name" instead.

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


Well, in fact our renderer will take care of this. If  there are multiple
"top" parts, we just create another top widget to contain these parts. I'm
not sure that this is UIML-compliant behavior though. Have we agreed that
there has to be one unique top part? Then it's probably best to change the
example.

Best regards,

-- Jo