IDE Minutes 2008-02-21

From MemberWiki

Jump to: navigation, search




  • Jon Ferraiolo, IBM
  • Lori Hylan-Cho, Adobe
  • Phil Berkland, IBM
  • Bertrand Le Roy, Microsoft
  • Rich Thompson, IBM
  • Stewart Nickolas, IBM
  • Marcos Caceres


(continuing to walkthrough the wiki page at:



Jon: Not in JSON schema. This attribute is being used by two different groups for two different things. Aptana's format has this as an enumration that indicates whether the given property is a class property or an instance property. Stew and the Gadgets TF is using it to indicate the JavaScript class that corresponds to the gadget. I think we need both.

Stew: Belongs in a more general API discussion. Discuss later all together. For us, it's the class name for the widget.

Jon: How about using 'scope' for same thing as Aptana is using and then 'jsClass' for the Gadgets requirement?

(no objections)

Tentative decision: 'scope' per Aptana, 'jsClass' for class name


Jon: Not in JSON Schema. This attribute is something that wasn't thought through when introduced and was a placeholder for custom validation logic in case regular expressions via 'pattern' were not sufficient. Does Dreamweaver have anything like this?

Lori: Have to look.

Rich: XForms has it.

Jon: And of course HTML has it.

Stew/Jon: Best to talk about this one in context of more general API discussion

Stew: Maybe getters and setters will provide this.

Jon: Rich, do you have any experience in this area?

Rich: Nothing like what we are doing here. Best to look at the APIs in general.

Tentative decision: Postpone discussion until future discussion of APIs in general

bracket syntax conflict: used by both array type and multiple types

Jon: At a previous telecon, we resolved to get rid of 'arrayType' and instead opt for a more compact syntax where the 'type' could specify brackets, inside of which was the type for the given array. But then I noticed that at an even earlier telecon, we were using the same syntax to specify a list of possible data types that were allowed. I can't remember if we separated types in the list with a space or comma or both.

Stew: Not sure if this is OK to bring up, but when I think of a list of types, I would expect a pipe to be the separator.

Phil: Could use braces instead of brackets

Jon/Stew: Simpler if we just include a list within braces

Jon: I like the pipes

Phil: Another possibility is to add an 'isArray' attribute

Jon: But that goes against our previous decision to embrace ECMA 262 types, where the 'type' attribute is one of the types from that spec, such as Number, String, or Object. The only tweak we are considering is replacing Array with the bracket shorthand.

Jon: Proposal: bracket to indicate array, lists of types accomplished using pipe separator.

(no objections)

Tentative decision: type="[Number]' for arrays (in this case, of Number), type="Number|Object" for something that can be either Number or Object, type="[Number|Object]" for array whose elements can be either Number or Object

<content> and <customUI>

Jon: OK, we finished the comparison table between OpenAjax and JSON Schema. Let's go to the Widgets Metadata wiki page. On that page there is an open issue that has been hanging around for awhile. In the Gadgets spec, there could be multiple <content> elements, where the 'type' attribute indicates whether the content is for inclusion into the web page, whether it is what should be displayed in 'edit' mode, or whether it is help text. For the current metadata spec as it stands, there are two elements. There is a <content> element that holds the content that is to be inserted into the web page. Then there is a <customUI> element that is used for edit, help or a custom property editor. A third approach comes from Dreamweaver where there are separate elements for each of these cases.

Lori: Let me understand. <content> is just for what gets inserted into the web page?

Stew: My thinking is that <content> and <customUI> are very close. Best to keep schemas as simple as possible. Provides an extensibility mechanism for other similar usages down the road.

Lori: For us, content is what gets inserted into the user's doc, nothing to do with the tool, everything to do with the widget. I would separate out the things that make the widget versus helps the tool.

Stew: Very similar in terms of attributes and content types.

Lori: Are you saying because they both have 'src' they should use the same tag? I am against that. I really want to keep separate what is going into the user document versus the tool.

(discussion about the 'sandbox' attribute)

Rich: The 'sandbox' attribute can apply to both in the mashup scenario.

Jon: Yes, with mashups, the tool runs in the browser, so sandboxing of tool-based markup applies.

Rich: Difference in the tag name may help it be understandable.

Stew: OK

Lori: Scott has added some new Dreamweaver-specific tags to the original Adobe proposal. Only affects Dreamweaver.

Jon: Lori, would you prefer separate tags for each different concept instead of <customUI> with a type attribute?

Lori: Either way, but Scott has gone with separate tags.

Jon: I don't think the syntax matters mcuh.

Camel case tangent

Stew: I see we are using camel case.

Rich: Camelcase helps things stand out.

Jon: We have never discussed this explicitly, but everything in the spec right now uses camelcase, with a first letter as lowercase. New words start with an uppercase letter. The other approach would be to have all tags begin with an uppercase letter. Personally, I don't care.

Back to <content> and <customUI>

Lori: Back to the question of one tag versus multiple tags. We don't care. But I'm wondering if we really even need these features. Is anyone else using it? Each tool will have different approaches.

Jon: For some of this, to achieve interoperability, we would have to define things more specifically, such as inputs and outputs for the extensions. Probably too much for now.

Jon/Lori: Let's drop <customUI>

Marcos: I support dropping it.

Stew: Gadgets have a different mode for editing. In mashup case, a computer-generated editor is OK for most scenarios, but not sufficient for all scenarios.

Rich: In browser space, becomes more critical. Need custom code. We need to enable the Gadgets case.

Jon: Sounds like it should be only required for Gadgets and mashups that run in the browser, and not a requirement on IDEs.

Tentative decision: Gadgets TF will send a proposal on custom UI for mashups running in the browser, traditional IDEs don't need to support this.

Personal tools