IDE Minutes 2009 03-31
- Jon Ferraiolo, IBM
- Javier Pedemonte, IBM
- Kin Blas, Adobe
- Lori Hylan-Cho, Aptana
- Adam Peller, IBM
- Stew Nickolas, IBM
- Bertrand Le Roy, Microsoft
(1) For CATEGORY element, proposed approach to a standard list of categories
Proposal: * In the short-term, create a wiki page, such as http://www.openajax.org/member/wiki/OpenAjax_Widget_Categories, where over the course of time, we would develop and maintain a list of shared category names. Initially, the wiki page would be an empty placeholder that just explains the purpose of the wiki page and that includes instructions to OpenAjax members for conventions for how to add proposed categories to that wiki page. * Over the longer-term, we would maintain the list of categories within the OpenAjax Registry (i.e., once the Registry is operational as a self-service web application).
Jon: Proposal to have separate wiki page. Reactions?
Lori: Seems like a nice way to go.
Jon: Consistent with other things we have done when facing similar situations. Any objections?
RESOLUTION: Separate wiki page for categories
(2) <require> tags and embedded content.
- Kin: http://openajax.org/pipermail/ide/2009q1/001044.html
- Jon: http://openajax.org/pipermail/ide/2009q1/001045.html
- Kin: http://openajax.org/pipermail/ide/2009q1/001046.html
- Adam: http://openajax.org/pipermail/ide/2009q1/001047.html
- Jon: http://openajax.org/pipermail/ide/2009q1/001048.html
- Kin: http://openajax.org/pipermail/ide/2009q1/001049.html
Jon: First, I wanted to comment on Adam's comments. Yes, we should only have one CONTENT tag that is active at once, for any particular mode. No concatenation of CONTENT elements. Things are already complex with multiple modes, and then we might adds views from OpenSocial.
Kin: My concern has to do with re-editing features in my long email. If we have only one CONTENT, we need other metadata for other types of insertions.
Adam: Why not just put other content within the CONTENT element?
Kin: I will write an email on this. Things people want to do in the IDE area, tweak the widget, where the user weaves content into the widget. How to do it? I probably lost lots of people.
Kin: As a separate issue, we need a way to include singleton content into the head. Particularly needed in order to insert things for IE5 and IE6.
Kin: I like that.
RESOLUTION: Postpone this to next week. Kin will send email.
(3) Roll "Mashable Widgets" features back into main metadata spec?
Related email about @singleton in IDE workflows:
Jon: Gadgets TF finished a few months process of due diligence and reworked proposals for the mashup features that were split off into a separate wiki page. They are done and request that the features get rolled back into the main metadata spec. This is because the mashup features are now as far along as the IDE widget features and because it will be simpler for all concerned if there is just an OpenAjax Metadata 1.0 with everything in it rather than a 1.0 for IDEs and a 1.1 a month later for mashups
Kin: One question. If we do merge, we need to be clear about what each tag means. For example, how the CONTENT tag works.
Stew: I agree both with this example and in general. Do not intend to change the semantics of existing tags for IDEs. Just additional markup for mashup scenarios.
Jon: I agree, also. I was planning to have the spec say which feature applies to runtime scenarios and which applies to IDEs. I was planning to put indicators in the spec for features that only apply to mashups such that an IDE developer would know that some features don't apply to him.
Kin: Namespace the mashup features?
Jon: I think that would be dangerous. Sometimes a gray line. For example, we pulled @singleton into the mashup area, but you said this week that there was value in this attribute for the IDE case. Instead of having a visual indicator such as mashup:attribute, I was thinking of a different visual indicator in the prose such as [MASHUP].
Jon: We are talking about 4-5 attributes as the only markup changes. There are APIs and events, but all of them only apply to the mashup runtime scenario and don't apply to IDEs. I was planning to put the APIs and events in a whole separate chapter clearly labelled as only applying to runtime mashups.
Kin: I've been attending the Gadgets phone calls. I'm fine with those.
Jon: Any objections?
RESOLUTION: Roll the mashable widgets features back into the main metadata spec
(4) Incorporate __BIDI__ substitution variables into metadata spec?
- Jon: http://openajax.org/pipermail/ide/2009q1/001051.html
- Jon: http://openajax.org/pipermail/ide/2009q1/001052.html
- Howard: http://openajax.org/pipermail/ide/2009q1/001056.html
(Jon explains how the four __BIDI* variables generally only apply to the outermost styling for a widget)
Jon: Comments or questions? Good thing or bad thing?
Bertrand: Good thing
Adam: Four properties cover the areas you need. My concern is how direction is declared. What is there was apparently good enough for Google.
Adam: I hope to hear from the IBM Middle East people on Friday
RESOLUTION: Postpone this until next week's phone call
(5) Issues with 'Locale' element
- Jon: http://openajax.org/pipermail/ide/2009q1/001053.html
- Howard: http://openajax.org/pipermail/ide/2009q1/001055.html
Jon: After further study, I have concluded that 'country' is wrong and that it should be dropped, and 'lang' should say any BCP47 identifier, which means deviating from OpenSocial.
Jon: Howard agreed. Any objections?
RESOLUTION: Drop 'country' and 'lang' holds a BCP47 string
Jon: Now that we have deviated from OpenSocial, why have a 'Locale' element instead of a 'locale' element? All other tagnames in our grammar start with lowercase
RESOLUTION: 'locale' element instead of 'Locale' element
(6) Is this localization example correct?
Jon: This is mainly targeted at Adam. There is an example in the spec that shows three Locale elements, one for 'fr-CA', one for 'fr' and one fallback. What if you locale is 'fr-fr'?
Adam: Use 'fr'
Jon: Just wanted to make sure that we drop trailing subtags until there is a match. Thanks.
Adam/Jon: But still questions about more complex situations. What if you have multiple languages in your current locale, such as fr-fr and de-de. If there is a file for 'fr' and one for 'de-de', which one would you use? The de-de because it is the most specific, or would you first exhaust the first language in the list?
Jon: My preference is: If BCP47 defines this, then you must support that algorithm. Else, maybe this could be a quality of implementation thing.
Adam: Another question: how to determine the current locale? HTTP headers show a list of locales, which is different than browser. I forget whether BCP47 addresses this.
RESOLUTION: Yes on some sort of algorithm to strip subtags to find the right localization file
RESOLUTION: Research BCP47 and postpone decisions until next week
(7)No default for 'lang' attribute
- Jon: http://openajax.org/pipermail/ide/2009q1/001057.html
- Howard: http://openajax.org/pipermail/ide/2009q/001058.html
Jon: Howard said +1. IBM expert recommended this. Any objections?
RESOLUTION: Remove default on 'lang'
Editorial work on mashable widgets features
Jon: I'll merge the features into the main spec as best as I can. Then let's all review it and figure out how best to do the spec.