IDE Minutes 2008-03-25

From MemberWiki

Jump to: navigation, search




  • Kevin Hakman, Aptana
  • Jon Ferraiolo, IBM
  • Phil Berkland, IBM
  • Ted Thibodeau, OpenLink
  • Ingo Muschenetz, Aptana


(continuing to walkthrough the wiki page at:



Kevin: We have concluded that there are some nuances with mixins that we haven't addressed yet.

Ingo: Have been talking with Dojo people. A couple of cases we don't express. Maybe I'll send email and then we can talk about it next week?

Kevin: OK. What can you say in general?

Ingo: Need to make it more reflective of the underlying JavaScript. Make sure there is a direct mapping.

ACTION: Ingo needs report back about proposed changes for mixins.


(discussion about whether there can only be a single constructor within variable arguments or multiple constructors with different arguments. concluded the former: only one constructor per class, but can take variety of arguments)

(discussion about Aptana's format. concluded that there is a visibility=public|private, no scope, mode is deprecated, and then a different attribute that flags whether a particular API is "advanced", which means an IDE doesn't show that API for most users.

Ingo: We use the "advanced" attribute quite a bit. OK if it is our namespace extension instead of a standard feature.

(discussion about how markup should look. agreement that separate <constructor> element is more readable, but in JavaScript a constructor is just a method. discussion about how we want to allow easy transforms to/from JSON, so it should be <methods>/<method> and/or <constructors>/<constructor>.)

Kevin: For JSON conversion, I prefer <method constructor="true">, with default of false.

Phil: 'constructor' attribute and 'name' attribute would be mutually exclusive

Ingo: Can you define mutually exclusive attributes in XSD? I think so.

Jon: I recommend RelaxNG for formal language definition. Definitely possible in RelaxNG.

Phil: In JavaScript, return type isn't necessarily the object. That is the result of a new.

DRAFT CONSENSUS: <methods>/<method constructor="true|false" visibility="...">

ACTION: Ingo needs report back about attribute that indicates "advanced".


Ingo: Child of 'class', 'method', 'property'. An element is better because we can have text content to say what to use instead.

Kevin: Perhaps useInstead markup for clarity?

Ingo: If an attribute, we might want it to be parseable.

Kevin: Anyone want an actionable list of pointers? Or is this too much for version 1

Jon: Too much for version 1. But we need to think through extensibility. One approach is that we only support text content today, but if we need to extend, we add child elements later.

Kevin/Ingo: Yes

DRAFT CONSENSUS: <deprecated> where child content is just text

Ingo: How to specify localizable content?

Jon/Kevin: We have an open issue on that across the whole language

Ingo: Maybe have IDs on each localizable element, or use $ for localizable strings

Kevin: Or @something@


Phil: Allow HTML?

Ingo: Has to be valid XML

Jon: What if the content includes advanced HTML features such as canvas or SVG that aren't supported universally yet? Just do your best job, and put burden on authors to include snippets that are portable?

Kevin/Ingo: Can use CDATA for non-well-formed HTML

Kevin: What about transcoding into JSON?

Jon: Possible, but not sure how hard. It's just a subset of the bi-directional escaping requirements.

Phil: Javadoc might define a subset of well-known HTML tags

Ingo: An example might use a wide variety of features

Kevin: What is description a child of?

(class, method, property, parameter, returns)

Jon/Ingo: Therefore, <returns type="..."><description>some text</description></returns>

Jon: Implicit <div> around everything in the description

(discussion that concluded that CDATA is only needed when content breaks XML)

DRAFT CONSENSUS: <description> can take HTML, if it breaks XML must wrap in CDATA, tool makes best effort to render, content is snippet that goes into an implicit DIV, burden on author to use a portable subset, will recommend and provide pointer to a portable subset

ACTION: Jon to research where a portable subset of HTML is defined such that we can reference it


Jon: What does this mean for JS?

Kevin: Let's skip until Bertrand is here


Ingo: Yes, but should be <examples>/<example>. Sometimes there are multiple examples.

Jon: Yes

Jon: Is an example always a <pre>

Ingo: Up to author to include any <pre>

Jon/Ingo: Implicit DIV around the example

Jon: Assume it is HTML if no namespace is declared.

DRAFT CONSENSUS: <examples>/<example>. Can take HTML like <description>. (See above)


Ingo: We should do like what is in Aptana's format, but clarify description.

Jon/Kevin: Agreed.

Jon: What is type? Everywhere else the 'type' can only be an ECMA262 type

Ingo: What if parameter is an object?

Jon/Kevin: ECMA "Object" type, but use JSON Schema once it is defined for defining the Object more.

Ingo: But need to refer to other types in the document. For us, 'type' is either an ECMA type or a custom type defined elsewhere in the document

Jon: Need to think this through.

Kevin: Pick up next week with exceptions.

are we going fast enough?

Kevin: We are about halfway through this document. At this rate we won't finish this matrix until the end of April.

Phil: Remaining items should go faster.

consensus: for now, let's keep going 1 hour per week and see how we progress

Personal tools