IDE TF Minutes 2007-06-14

From MemberWiki

Jump to: navigation, search

Attendees this week

  • Jon Ferraiolo <jferrai(at)>
  • Phil Berkland <berkland(at)> representing Eclipse ATF project
  • Greg Murray <greg.murray(at)>
  • Ingo Muschenetz <ingo(at)>
  • Kevin Hakman <khakman(at)>
  • Wayne Beaton <wayne(at)>


Apologies in advance. I tried really hard to make sure that comments were attributed to the right speakers; but I may have made some mistakes.

Kevin: Week from today, creation call to formalize and update into a full working group status.

Going through the requirements, but at same time, we've found that in parallel to the requirements process, sample implementations, manners in which the requirements can manifest are helpful. Notices to members have been put out soliciting such implementations. Nobody on the call has done this yet.

Good way to collaborate, get lots of eyeballs on your implementation.

Kevin: Significant decision: metadata files must be in XML format.

Greg: I would have said no, should I have been there.

Kevin: Format that's easily convertilble between JSON, XML, and other formats. Perhaps derive some kind of utility for doing conversion between XML and JSON.

There was a vote, not necessarily a final vote. There was a consensus that we should word the requirements.

Greg: Is it our mandate to say that it should be one or the other. JSON format is friendly for NetBeans/Eclipse, but maybe not for others.

Kevin: the idea that I was promoting is that the 'master format' must be XML, but that we must provide the XML in a format that can easily be translated into JSON.

Use a subset of XML schemas to create the master XML document.

TIBCO is more XML-centric which makes Kevin biased.

Greg: One of my design criteria is 'no XML'.

Kevin: What we're working on is a requirements document. Requirements document is a initial document. I'm advocating a format that can be translated between XML and JSON. 60% weight on XML (Support for schema and validation). Support for growing JSON community and solutions that are wholly JavaScript.

Phil: Main rationale is that XML support is widely available in IDEs; infrastructure for XML is better than that for JSON. I don't think we need to nail it down in the requirements document.

Greg: worried about such strong language occurring this early in the evolution of the requirements document. I'll shut up now.

Kevin: Don't shut up. Maybe the metadata files should be implemented in a manner that you can translate between XML and JSON instances. Which defers how we go about doing that, but preserves the idea.

Phil: How about we do what you said, and then add "defined in either XML or JSON". Note: the consensus of the task force is currently leaning toward XML.

Kevin: XML has some benefits for pre-existing IDEs.

Phil: Ok. Does anybody object to me changing the line in the requirements?

Nobody objects.

Greg: we'll have to decide which one it is.

Phil: When we start writing the spec, we'll have to decide.

Greg: Ant task that generates documentation; we use that to validate. Nice thing about JSON is that you can embed objects. There are plus and minuses on both sides.

Kevin: Ingo, Aptana has done some work in this area. What pros and cons have you found?

Ingo: XML used internally. Nice, especially for doing documentation. Translate into XML or JavaScript version.

Kevin: Why XML?

Ingo: Given the amount of doc we had to construct, it was easier to look at an XML document. JSON harder to look at, especially for a novice user. You can do it, but you may require a little extra tooling on top, instead of just an XSLT.

Kevin: Let's leave this for now, we'll update the wiki page.

Greg: Is there a description of the information we want to capture

Kevin: That's what the requirements document is for. {Kevin discusses some specific examples from Bertrand in the document.} The should may and must in the req doc are essentially prioritization indicators for what the tf should pursue. As opposed to whether a value for an element is required or not required. Example: the meta data should provide means for vendor behavior of what would be valid entry for that. By extension, to the extent a vendor does not want to provide that value. Our schema should contemplate the ability for people to assert what is going tob e a valid entyr for that property.

Jon: In terms of should vs. may, should provide valid options for entry of values for certain behaviour. It's a pretty confusing requirement. Talking about valid options for properties. Enumerated lists can be expressed in XML or JSON, Behaviour is harder.

Kevin: Trying to be broad and inclusive.

Jon will send email to group proposing changes he would like to make.

Kevin asked about some questions posed by Bertrand in the document. Jon will answer the questions.

Kevin: Do we need to take it upon ourselves to handle dependencies between components, or should the users make sure that they have the dependencies properly configured.

Phil: OpenAjax should be advocating that library releases are backwards compatible. Should be required for an Ajax vendor to get the seal of approval.

Kevin: Deprecation is a natural part of the process. functionality supported for minimum of 2 releases.

Phil: Agreed that deprecation is just a part of this. But should be the exception rather than the norm.

Kevin: Natural process. Community will reject toolkits that are not backwards compatible anyway.

Phil: Change must to should?

Notion of a library. Metadata on a library. Specify dependencies (maximum/minimum version numbers)..

Greg: JMaki just specifies a minimum.

Wayne: How do you properly specify a maximum? Why not specify a minimum version and have toolkit specify previous version it is compatible with.

Kevin drops off (unexpectedly), Jon summarizes what he thinks Kevin was going to say: Need a mechanism to identify deprecated features.

OSGi is too heavy. Need some subset.

Jon: Phil, can you capture mechanism for the IDE to be able to identify deprecations?

Phil: Change it 'should'?

No disagreement.

Kevin comes back.

Line starting "Metadata must be easily updated by library developers." When IDEs are being used to create/update components, metadata must be kept up to date with changes to library.

Jon: What is the use case behind this requirement. Is the IDE being used to create an Ajax Library.

Phil: The first case.

Metadata includes links to documentation, samples, etc.

Jon: Probably too much to try and address library developers as well.

Need a metadata format that's easy to update. Must be easy for library developers to update the metadata to reflect changes. Keep it simple so it's easy to update. Easy to rerun scripts to generate docs, API definitions, etc.

Primary workflow is for developers *using* libraries. Pie in the sky for developers *building* libraries.

Even a JavaScript function should fall under this? Should the metadata be updated to reflect the additions.? Is the update immediate?

Kevin: Does anybody want to put together a strawman implementation to get the ball rolling?

Kevin: Creation call next week. Information is on the IDE charter page. 9am pt, 12pm et.

Next week, we'll do the regular call (8am pt) and the creation call at 9am pt.

Personal tools