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

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

Hi Jo,

Thank you for your feedback!  Please see additional comments below:

On 12/3/07, Jo Vermeulen <jo.vermeulen@uhasselt.be> wrote:
> 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"?
>

Agreed, although Robbie's earlier e-mail definitely gives us something
to think about.

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

Agreed!

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

No this is not something enforced by UIML.  UIML is agnostic to how
the underlying implementation handles this case.  Maybe instead of
changing the example, we should just include an extra paragraph
explaining why the container doesn't have to be there.  Jo, would you
mind contributing such a paragraph?

Regards,
Jim