[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]