That's another good point, Jo!
On 12/3/07, Jo Vermeulen <> wrote:
> On Dec 3, 2007 3:42 PM, Jim Helms <> wrote:
>
> > Hi Jo,
> >
> > Thank you for your feedback! Please see additional comments below:
> >
> >
>
> Just another remark. I think we have the same problem in the vocabularies.
> Well at least in ours. We used to define two properties with id equal to
> "content", one was a setMethod and another a getMethod. This is in fact the
> same problem, since they have no unique id ...
>
> -- Jo
>
> >
> > On 12/3/07, Jo Vermeulen < > wrote:
> > > On Dec 2, 2007 8:49 PM, Jim Helms <> 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?
> >
>
> No problem! :-)
>
