IDE Minutes 2008-04-10
From MemberWiki
- Kevin Hakman <khakman(at)aptana.com>, Chair
- Phil Berkland <berkland(at)us.ibm.com> representing Eclipse ATF project
- Bertrand Le Roy <Bertrand.Le.Roy(at)microsoft.com>
- Ingo Muschenetz <ingo(at)aptana.com>
- Lori Hylan-Cho <lorihc(at)adobe.com>
- Jon Ferraiolo <jferrai(at)us.ibm.com>
Bertrand: Proposals for properties and enums not done yet.
Jon: need to understand and coordinate with widget metadata on third point so that overlapping concepts are coordinated.
Ingo: Mix-ins not ready, will present on Tuesday.
Jon: 4th bullet, nobody seems to remember what namespaces this is referring to (under availability), maybe related to registry-defined namespaces.
Kevin: let's move on as we had a good discussion on that. Subset of HTML usable in summaries?
Jon: we would recommend white listing here for security reasons. We don't enforce it in the spec.
Kevin: it's the burden of the IDE vendors to handle that, unwrap CDATA sections, etc. We just recommend best practices and don't impose anything except for wrapping in CDATA.
Jon: it means IDEs will need to be able to deal with CDATA and that HTML contents may not be well-formed.
Ingo: people could encode into entities as an alternative to CDATA.
Jon: the tool is either going to have a browser engine or deal with extracting text and entities, etc.
Lori: sure, we can display that. Why would we need to deal with invalid html?
Phil: wondering what would happen if it's malformed but should be ok.
Jon: let's ask vendors if this is likely and just warn them this may happen.
Ingo: why not use XHTML?
Jon: more likely to be portable
Ingo: the information will often not be displayed in a browser so well-formed will be easier to handle.
Kevin: encourage toolkit vendors to provide well-formed but warn IDE vendors that this may not be the case.
Jon: we should include notes for both ends.
Bertrand: we should recommend that the contents should remain readable as plain text.
What about spaces and new lines?
No need to be that detailed, what matters is that it remains readable if tags are stripped.
Jon: one strategy is to strip oiut the markup so toolkit vendors should take that into account in the way they write contents.
Phil: What about JS?
Kevin: Should or even must be avoided.
Jon: need a section on those topics, will write it.
Kevin: next item is using type only for datatypes. Can Jon give more context?
Jon: parameter, returns and several others have type attributes, the class element has a type attribute. Are they the same concept? It should be called name or something other.
Kevin: It's self-referential.
Ingo: It's the same in our case.
Jon: do these types have JavaScript dot notations? like dojo.foo
Ingo: yes.
Bertrand: same for us.
Jon: what about api type=javascript?
Consensus to shift from type to language here.
Same thing for Exception, Interface.
Jon: we have a chapter on datatypes, we should link to it.
Jon: we have multiple constructor and method definitoins, what about parameter or return types.
Phil: we had a discussion on that.
Jon: we decided it was useful for constructors and methods, what about parameters and returns values?
Bertrand: there isn't a scenario that is not covered here, whereas for overloads, you couldn't express different *combinations* of parameters.
Kevin: any other open items? (no answer)
Jon: we've made lots of progress for API and should start moving on to widgets.
Kevin: Adobe has lots of experience on snippet-driven authoring.
Lori: we made the widget draft
Kevin: would like to put Lori's proposal into a comparable matrix.
Jon: who's creating the matrix?
Kevin: Lori, could you make a first draft?
Lori: Which format should I follow?
Kevin: Jon can set-up a wiki page?
Jon: instead of creating a matrix, we got far on widget metadata so maybe put comments in the existing document showing differences. I'll send a link.
Lori: our differences are already in the proposal. Questions around how ids relate to elements on the page, attribute substitution, etc.
Jon: looks like macro expansion
Lori: is actually more specific
Jon: do you use braces?
Lori: no, use @ before and after
Jon: who says what the supstitution rules are?
Lori: we just substitute wherever we find @@
Jon: can you write email to explain?
Lori: sure.
