IDE TF Minutes 2007-07-12

From MemberWiki

URL: http://www.openajax.org/member/wiki/IDE_TF_Minutes_2007-07-12

Attendees this week

• Jon Ferraiolo <jferrai(at)us.ibm.com>
• Ingo Muschenetz <ingo(at)aptana.com>
• Kevin Hakman <khakman(at)tibco.com>
• Phil Berkland <berkland(at)us.ibm.com> representing Eclipse ATF project
• Bertrand Le Roy <Bertrand.Le.Roy(at)microsoft.com>

Minutes

Jon: Had been looking through Microsoft XML schemas and thought they were good work but wondering about licensing.

Betrand: The license is meant to allow creative and derivative work and the intent is meant for broad expansive use.

Ingo: I've added Aptana's XML and JS commenting formats to the IDE task force page.

Kevin: Regarding the requirements, there are about 50% green, 50% red. I encourage section owners to convert red comments to green.

Kevin: I don't want to get bogged down in nomenclature, but we should nail those down.

Jon: My vote is to approve Ajax element, API and control items.

Phil: Fine, but seems that these terms might be defined in multiple places in the OpenAjax wiki.

Jon: I don't think they are in direct conflict with any other definitions. I can check that out.

Phil: Perhaps we create a central page that all groups can link to?

Kevin: We can reorganize later once the document has been approved.

Jon: To me a toolkit is a library + other things. For MS Ajax, for example, the toolkit consists of ASP + generated JS, the IDE, etc. If people think that definition is okay, I'll add toolkit into the definitions for this page.

Jon: I think we can approve the definition of component

Kevin: Any objections? (none)

Kevin: Jon, did your last comment about requirements and JSDoc get incorporated into the general requirements.

Jon: Looking through--no. My point is that there is a sizeable community that uses the JSDoc syntax. We don't have anything about accommodating the existing use of JSDoc and when we decide our XML format, it should encapsulate the features of JSDoc.

Kevin: I like that comment and a smart move.

Betrand: I accidentally picked the same name as an existing ScriptDoc project for the Microsoft tool. Should I change the name of my tool? Ingo: It would be helpful to remove confusion.

Kevin: To what extent does the MS Microsoft format accommodate the JSDoc syntax?

Betrand: I think it can accommodate the features of JSDoc.

Jon: Both Microsoft and Aptana have gone further with their formats as a product/commercial level of implementation and added a link to the wiki and xml description. Both are product level description and are in products with two mature submissions. We should move to pros and cons of each format.

Kevin: Requirements: Let's move onto General.

Kevin: First bullet.

Bertrand: Suggest moving "open standards" to "industry standards".

Ingo: Seems like more of a philosophy for the entire document.

Kevin: This bullet is probably not worth the discussion. All in favor of nixing the bullet? Yeas win.

Kevin: Next bullet with XBL.

Jon: XBL is a component definition language. XBL is like the component tree definition language in XAML. Also similar to HTCs. It's part of the Firefox shipping version and came back to W3C and part o the Adobe SVG viewer

Kevin: If we can generate that synergy, great, but it's a very soft requirement.

Jon: There's no pieces of the XBL spec that includes IDE requirements, so anything we do there could be helpful long-term.

Kevin: Objections to approve? (none)

Kevin: "Accessibility" bullet. Concerned about the "MUST" status as I'm not sure about the availability of requirements here.

Bertrand: Is there some data about accessibility that we know exists in metadata?

Kevin: At the very minimum, there could be some data about the accessibility in the metadata?

Ingo: Section 508 compliance would be a useful thing to note when developing a page with components.

Bertrand: Perhaps an extensibility mechanism would be useful.

Ingo: That follows what we have seen with our uses

Kevin: I like extensibility, but not sure accessibility and localization are part of that. Let's separate the difference between requirements and implementation.

Kevin: Mark as approved.

Kevin: Next item: Must describe localizable controls.

Kevin: Mark as approved.

Kevin: May be designed to cleanly separate out non-localizable data from localizable data. Seems like a soft requirement. Any objections to soft MAY requirement?

Kevin: Next requirement: Standalone metadata file. We've intentionally removed the inline annotation piece in this bullet as the next bullet encapsulates that idea.

Kevin: Approve the next two bullets

Kevin: Bullet about translating between JSON and XML

Ingo: Greg had some issues with the ease of use of XML vs. JSON.

Kevin: I believe it was that sometimes describing an property as an object is inefficient in XML as you had to resort to using CDATA all over the place. I still think the language is good, so that people can use an XML path or a JSON path when describing metadata.

Bertrand: Does that mean that we would need to understand JSON and XML formats?

Kevin: I have a strong bias that the specification format be XML, but that's not explicitly stated.

Jon: I suggest that they "MUST" should be replaced with "SHOULD".

Kevin: The bullet above suggests that the metadata file will be XML.

Kevin: Betrand's section--please convert to red to green by next meeting.

Betrand: Sure.

Kevin: Let's start with Phil's section. Should include release level of control and APIs.

Kevin: Mark as approved.

Kevin: Next item: Should describe the resources on which a control depends.

Kevin: Mark as approved.

Jon: What about Betrand's comments?

Phil: Those have been incorporated.

Jon: Should we remove comments?

Kevin: The current convention is that those comments have been approved.

Kevin: Next comment is breaking changes with previous versions.

Kevin: Objections? Approved.

Kevin: Next bullet is "indicate associated licenses"

Phil: Maybe it should go to "May"?

Kevin: Field should be mandatory, value can be optional.

Ingo: Components could be under multiple licenses

Kevin: Editing to handle the case where there are multiple applicable licenses. Any comments? Mark as approved. We're very close to the vote of the steering committee for the formalization for the working group. Next meeting is next week. Does that work for all? (consensus is yes)

Kevin: Tried to reach out two names from Infragistics. Jon, did you get those?

Jon: I couldn't get their emails.

Kevin: I'll send those along.

Kevin: Has anyone contacted the guy from JSDoc?

Ingo: We attempted to contact him but no result. It seems it's a partially abandoned project.

Kevin: Since we are moving into issuing a specification this year, that might be reason enough to motivate some groups.

Kevin: See you all next week!