IDE Minutes 2009 02-03
- Jon Ferraiolo, IBM
- Kin Blas, Adobe
- Lori Hylan-Cho, Aptana
- Nitin Dahyabhai, IBM
- Bertrand Le Roy, Microsoft
- Adam Peller, IBM
Move some unimplemented features into a Futures appendix?
- Library metadata
- Inclusion features
- The "openajaxmetadata:" protocol
Lori: Totally reasonable
(Jon lists the features)
Bertrand: openajaxmetadata: is important. How do you reference other objects? Makes <reference> marginally useful, but if no one is using it, then fine.
Jon: I'll send out a FINAL NOTICE email. If no one responds, it goes to the Futures appendix.
RESOLUTION: Move the 3 features to a Futures appendix
Move topic features into supplemental "Mashable Widgets" spec?
Should we move the <topic> element and the topic attributes on the <property> element (i.e., 'topic', 'publish', 'subscribe') to the supplemental "Mashable Widgets" spec:
- Jon: http://openajax.org/pipermail/ide/2009q1/000955.html
- Lori: http://openajax.org/pipermail/ide/2009q1/000959.html
- Rich: http://openajax.org/pipermail/ide/2009q1/000960.html
Jon: It's OK to leave these in the spec now, but since these seemed to be mashup features, maybe they should be moved.
Lori: Yes, it makes sense. Mostly for mashups.
Jon: Rich says they should stay.
Lori: Doesn't that make them into mashable widgets?
Kin: Does <topic> element mean the events go through the Hub?
Jon: Yes. This is to identify events that will be transmitted through the Hub.
(Jon and Kin agree with Rich. Reasoning is that Hub 1.0 works in developer workflows, not just end-user mashups, and topics are things that can work with either Hub 1.0 or Hub 1.1. The way a tool that support the non-mashable widget metadata could deal with topics is to simply make sure there was an OpenAjax.js if there were any topics in the metadata. A widget then could invoke the Hub 1.0 APIs.)
RESOLUTION: Don't move the topic features
Metadata spec editorial updates (per last week's phone call)
- (1) Remove all of the blue-colored comments that say things like
"2008-05-29 Tentatively approved". Let's just assume that everything that exists in the spec today has been tentatively approved.
- (2) Then we do final review the various sections of the spec and add
color-coded notes to indicate status:
- (a) No color-coding indicates that final review hasn't happened on that
- (b) Green-colored Approved indicates that a section has been reviewed and
that the text for that section is approved for inclusion in the final spec
- (c) Purpled-colored comments highlight instructions to the editor for
improving the wording in that section of the spec.
- (d) Red-colored comments reflect issues that require further discussion and
- (1) We do not currently have any metadata, such as a 'lang' attribute, that
says what language is used for the content within the main metadata file. I propose that we add a 'lang' attribute to our root elements (<widget> and <api>), with a default value of "en".
- (2) We have decided to follow the W3C's lead with its widget format about
how to allow for override localization files, but there is a red-colored issue in the Localization chapter about what folder holds the localization files. The W3C has decided that localization files are located within a 'locale' subdirectory. I propose we update our spec so we fully align with the W3C approach.
- Jon: http://openajax.org/pipermail/ide/2009q1/000957.html
- Marcos: http://openajax.org/pipermail/ide/2009q1/000958.html
Kin: Would the default by 'en'?
Jon: Yes. Is this OK, Adam?
Jon: Any objections to adding 'lang'?
RESOLUTION: Add 'lang' attribute to <widget> and <api> elements
Jon: Marcos points out the folder name is 'locales', not 'locale'.
Adam: What about fallbacks?
Jon: Ultimate fallback is whatever is used in the base folder, say English
Adam: What about country, region fallbacks. There are various rules.
Bertrand: Some situations have 3 levels deep. I know of two cases.
Adam: Chinese has multiple
Kin: Is there an algorithm?
Adam: Yes, there is a spec.
(We look at the W3C Widgets spec)
Adam: BCP27 sounds familiar
(We discover the algorithm in the W3C Widgets spec)
Adam: How do you do Web lookup? Via client-server query APIs?
Jon/Adam: Yes, that's the only way
ACTION: Jon to edit spec to include fallback algorithm