IDE Minutes 2008-05-20
- Kevin Hakman, Aptana
- Jon Ferraiolo, IBM
- Phil Berkland, IBM
- Rich Thompson, IBM
- Lori Hylan-Cho, Adobe
- Jeff King, Microsoft
- Stew Nickolas, IBM
Summary of current status
Kevin: We are at a point where most of the concepts have been discussed and we have tentative approvals on most things. We are ready to rub up some prose and work through nuances.
Kevin: Concurrently, a next major step is to move into the first part of an InteropFest. Next two months we want to garner participation with widget makers and tool vendors, both IDE and live mashups.
Jon: We talked about a timeline on Thursday.
Kevin: Stable complete spec by June 30. Participation in July and August. Assume changes to draft spec in response to first wave of tests around August 15. Completion on Sept 15, and then promotion.
Jon: Probably would promote at AJAXWorld in second half of September.
Stew: We are working of course on the reference implementation. But we have been talking also about a widget repository, maybe at openajax.org. Thin layer on Open Search.
Jon: We have been working with some partner companies that aren't OpenAjax members. There will demos of compatibility with at least a couple of major mashup players.
Kevin: Any plans for JSDoc people to write transcoders?
Jon: They promised coordination but I don't remember promises on software. Need to look into that. I would hope it wouldn't be too hard to convert JSDoc into OpenAjax format.
Kevin: For producers, widget and API providers could point to a metadata file and we will create a web-based validator. For consumers, mashups or IDEs, best if there is a publicly accessible environment that shows success. For Aptana, might post a beta and maybe a screencast.
Jon: OK for producers to either post a screen capture showing success or just a plain text statement that claims success. Not likely that we will see false claims.
Kevin: Lori, what might Adobe do?
Lori: What does it entail?
Kevin: Attempt to pass the test so we can get technical feedback and them there is a promotional aspect
Lori: Not sure what our role will be because we don't know how public we can be
Jon: I wanted to point out that it's OK for products with existing XML formats, such as DW or MS, to transcode our format into existing format and load the transcoded result
Lori: We might support it directly
Jeff: Bertrand will make the call for us. We are in between releases, maybe we can make a standalone version.
Kevin: At Aptana, we may not support OpenAjax Metadata on day one. Ultimately we will go native with it. Our format now is highly similar. No widget support now, but that's a potential new area for functionality.
Phil: We should be able to show something. Too late for the next Eclipse release, but hopefully for the next non-maintenance release.
Escaping strategy on substituted content
Kevin: There is a red item on the widgets page saying Jon needs to submit a proposal for escaping for substitution strings in content
Stew: Just use CDATA
Jon: Sounds good
Kevin: Any objections?
Kevin: Question about documenting the commonly used widths and heights. Isn't it just 16 and 32?
Lori: Dreamweaver uses 18 and 36. We will scale the other sizes.
Rich: Key thing is to say that different tools need different sizes and here are some examples.
Kevin: Maybe a wiki page that shows sizes that are used?
Jeff King: We will scale, too.
Jon/Lori: Wiki page sounds like a good idea
Jon: I was wondering if there was a better root tag name for our included files that was less confusing.
Jeff: First thing that comes to my mind is 'fragment'
(various people say positive things, resolution is 'fragment')
(we weren't sure if that was approved. Lori thought it was. Just in case, we approved it again)
listen or subscribe
(we agreed that the attribute names should be 'publish' and 'subscribe')
<property> element red-colored note from Stew
Stew: Can remove that note
<see> and <seealso>
(decision to wait for Bertrand to return)
<require> 'type' attribute red-colored note
(ok to remove - we resolved this with <include> element)
<widget> element attributes
'width' and 'height'
Stew: For mashups, these attributes mean "best displayed at", but up to mashup canvas
Jon: What does Dreamweaver do about width and height?
Lori: Not in our metadata. Controlled by HTML and CSS
Jon: For mashups, it is just a hint. Therefore, can be ignored by a tool.
Lori: Why not just include it into the canvas with the mashup?
Jon/Stew: Some problems. Sometimes the content is put into an IFRAME for security sandbox reasons, and IFRAMEs don't support auto-sizing.
Kevin: Optionality is the right strategy but 'height' sounds like it saying what it must be
Jon: Could call it preferredHeight. Tradeoff of clarity vs brevity. What does Google Gadgets have?
Stew: height Default is 200x300
(discussion, everyone was accommodating)
Kevin: Leave it as width and height
Jon: What is not specified?
(decision: if specified, invoke constructor from the specified class. otherwise, mashup tool can choose to invoke a constructor that it provides)
Lori: For our format, this was the location which held the original XML file. Not using it now, but might use it in the future, such as for automatic updates. Was modeled after URL on DOCTYPE
Jon: I prefer that we drop things that won't be implemented now and restore when it does get implemented
(decision: drop 'location')
(decision: now a <license> element)
Kevin: Short description, not necessarily unique
Lori: Probably wouldn't be unique
Kevin: Namespacing due to class definition
Lori: We will use some combination of author and name
Future phone calls
(discussion, decision to have them once per week on Thursday, starting next week, one day after Gadgets phone call. Therefore, next phone call in 9 days)