From MemberWiki

Contents 1 Attendees 2 Minutes 2.1 Discussion of config element 2.2 event proposal 2.3 field discussion 2.4 datatypes 2.5 discussion of removing id attribute on widget 2.6 wording for usage attribute (static vs instance) 2.7 discussion of datatype name case (allowing lower case) 2.8 discussion of includeRef attribute 2.9 discussion of moving gadget feature to different spec

Attendees

• Lori Hylan-Cho, Aptana
• Kin Blas, Adobe
• Jon Ferriaolo, IBM
• Phil Berkland, IBM
• Rich Thompson, IBM
• Scott Richards, Adobe
• Bertrand Le Roy, Microsoft

Minutes

Discussion of config element

Bertrand: not important to have name attribute (JON correction: I believe he said it doesn't make sense without name attribute)

Jon: what would we do with name

ok with latest proposal

event proposal

Bertrand: is there a way to describe callback function parameters

Jon: add a handler element to config element which has parameter types

Jon: let's discuss this in email, will go ahead and drop parameter and returnType elements

field discussion

will drop field element, will use managed attribute on properties to indicate if getter/setter methods are used

no objections to proposal

(JON correction: we also agreed to a 'managed=true|false' attribute on <properties> element)

datatypes

datatype can be ecmascript type, brackets for arrays, new value for HTMLElement, ok for tools to apply heuristics

Bertrand: does this include window, document?

Jon: no, would use Object for those cases

Lori: should add datatypes for Window, Document, Node

agreement to add those 4 new datatypes

Jon: if convertor doesn't understand something, should it pass thru, and allow ides to apply heuristics to that element to try to understand it

agreement that convertor should do the best they can in converting, but it is ok to let IDEs apply heuristics

discussion of removing id attribute on widget

since dreamweaver is already using, leave it in

wording for usage attribute (static vs instance)

no comments

discussion of datatype name case (allowing lower case)

agreement that each datatype name will have 2 possibilities, capitalized, or all lowercase (JON clarification: for built-in ECMA types only, both initial uppercase and inital lowercase)

discussion of includeRef attribute

Scott: we need to check implementation and see if auto is being used (JON clarification: subsequently, Scott said he doesn't use auto, so includeRef has become a boolean)

discussion of moving gadget feature to different spec

Kin: we are using JavaScript element

agreement to remove all but JavaScript element