[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [uiml-comment] Summary of issues raised by Takashi Endo and suggested UIML 4.0 changes
That's another good point, Jo! On 12/3/07, Jo Vermeulen <jo.vermeulen@uhasselt.be> wrote: > On Dec 3, 2007 3:42 PM, Jim Helms <jhelms@gmail.com> 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 < 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? > > > > No problem! :-) >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]