IDE Minutes 2009 03-03
- Jon Ferraiolo, IBM
- Javier Pedemonte, IBM
- Kin Blas, Adobe
- Lori Hylan-Cho, Aptana
- Adam Peller, IBM
- Rich Thompson, IBM
- Phil Berkland, IBM
Jon: We OK on this one?
Lori: Yes. Just need to tell the jQuery engineer to modify their converter
(7) Status report from Lori on spec examples
Lori: I've been too busy to work on examples
Jon: Plans going forward?
Lori: jQuery generator only shows a handful of features. Need to use other toolkits for other features. I don't have YUI and Dojo metadata now
Jon: I can create YUI. We have an open source YUI to OAM converter.
Adam: Dojo is now generating something that is pretty close. Modeled after Aptana Scriptdoc.
Kin: Are vendors supposed to convert their own formats or use this format natively
Jon: Either. They can use it natively, or convert into it themselves, or work with IDE vendors to convert, or work with 3rd parties. We will evangelize to them that one way or another down the road they include OAM metadata in their distributions.
(2) LIBRARY element (instead of REQUIRE type=library)
Kin (after checking): We have a widget supplier that does use REQUIRE type=library. We could change our code to support both so long as we don't change the semantics
Adam (looking at Jon's proposal): The containment approach with REQUIRE inside of LIBRARY is interesting.
Jon: Seems natural to me
Adam: The other approach would be to just change REQUIRE type=library to LIBRARY and leave everything else as is. I feel I've seen more flat than hierarchical in the Ajax world
Jon: Any other opinions?
Kin: If you go with the hierarchy approach, then you don't need the 'library' attribute on REQUIRE, right?
Jon: Let's not make a hasty decision. Don't need to. Let's think about it for a week and then make a quick decision a, b, or c at next week's phone call
(3) Add 'lang' attribute wherever 'locid' is
Jon: Proposal to add 'lang' on every element that contains potentially localizable text
Rich: Tells you what the inline text is so UA can either use it or replace it with a different localized string
Kin: How does this relate to %%
Jon: The 'locid' is for replacing whole elements. Mostly for DESCRIPTION, TITLE, SHORTDESCRIPTION and similar things. The 'locid' is a key into a localization bundle. The inline text is the fallback. The %%foo%% syntax is mostly for CONTENT elements where most of the content is HTML markup, which you don't want to localize, but there are substrings that need replacement, such as the content of an H3 element within the CONTENT
Adam: How would you act on the 'lang' attribute?
Rich: We consider it as part of the localization data. We found that users were copying/pasting content among widgets within global development teams, so some of the descriptive text might be in a different language than the rest of the widget.
Adam: That's interesting. I understand why it's there. I guess 'yes'. But still confused by the whole localization scheme we have.
Jon: Any other comments?
RESOLUTION: Add 'lang' wherever 'locid' is for now, but we need to do a full pass on the localization features to make sure they are good
Jon: About 10 emails, talked about how there are really two separate use cases, and ended with Howard, Rich and I saying to drop it. Any objections to dropping?
Kin: The feature is mainly for mashable widgets?
Jon: Yes, but we thought for awhile that maybe their might be an IDE use case, but that's too complicated for now.
RESOLUTION: Drop view=insert
(5) Adam's open source implementation of OpenAjax widgets (including mashable widget APIs)
(6) Concrete proposals on "Mashable Widgets"
Jon: I sent email on this. IBM people have been doing tons of research on the mashable widgets spec and is ready to present various concrete proposals within a restart of the Gadgets TF. Will start meeting next week. The proposals are still being developed, but are solid enough for group discussion towards consensus. Any comments or questions?