IDE Minutes 2009 03-31

From MemberWiki

Jump to: navigation, search




  • 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

* In the short-term, create a wiki page, such as, 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's requirements:
* There is a need for a way to insert *static* content into the head.
* There is a need for a way to insert templated content into the head.
* There is a need for a way to insert templated content into the body.
* Is there a need to specify at start or end of body?
* Is there a need for inserting a static singleton instance of some content into the body? This would mean we would have to support multiple <content> instances being inserted into the <body> at the same time.

Jon's comments:
* CONTENT and JAVASCRIPT are instance-based and result in markup going into the BODY.
* REQUIRE and LIBRARY are static-based and result in markup going into the HEAD.
* My feeling is that if we want something that is static-based that results in markup going into the HEAD, it should either be an extension to REQUIRE or a new element that is a companion to REQUIRE.

Adam's comments:
* I was under the impression that there was only one (active) CONTENT tag per widget (which Jon confirmed)

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.

Jon: I think that's a good feature. A generalization of inline type=javascript and type=css. But what's the markup? I was thinking REQUIRE type=inline

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

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

Personal tools