IDE Minutes 2009 02-03

From MemberWiki

Jump to: navigation, search

URL: http://www.openajax.org/member/wiki/IDE_Minutes_2009_02-03

Contents

Attendees

  • Jon Ferraiolo, IBM
  • Kin Blas, Adobe
  • Lori Hylan-Cho, Aptana
  • Nitin Dahyabhai, IBM
  • Bertrand Le Roy, Microsoft
  • Adam Peller, IBM

Minutes

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: 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

particular section.

  • (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

resolution.

(no objections)

Localization details

Proposals:

  • (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.

Kin: Would the default by 'en'?

Jon: Yes. Is this OK, Adam?

Adam: Yes

Jon: Any objections to adding 'lang'?

(none)

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

Retrieved from "http://www.openajax.org/member/wiki/IDE_Minutes_2009_02-03"
Personal tools