IDE Minutes 2009 07-21
- Lori Hylan-Cho
- Kin Blas, Adobe
- Javier Pedemonte, IBM
- Jon Ferraiolo, IBM
- Howard Weingram, TIBCO
Any products out there with %% localization support already?
Jon: http://openajax.org/pipermail/ide/2009q2/001196.html Jon: http://openajax.org/pipermail/ide/2009q3/001202.html Kin: http://openajax.org/pipermail/ide/2009q3/001203.html Jon: http://openajax.org/pipermail/ide/2009q3/001205.html
TIBCO is running into a conflict with existing products which already use similar syntax and is wondering who has implemented %% and if this can be changed (perhaps ## or ~~ or __MSG_key__ like OpenSocial). Jon's 3 options: (a) Keep what we have with %%, (I'm against that given how this is very problematic for one of our key early adopters.) (b) Replace %% with a different two-character sequence for localization, such as ##. For example, ##MyLocalizationVar## (c) Adopt OpenSocial's localization variable approach: __MSG_MyLocalizationVar__ Jon's recommendation is (b): simply replace %% with ##. (The 1205.html email provides rationale.)
Jon: After thinking things through, and particularly how to integrate entityencode() and escapequotes() into OpenSocial syntax, I came to the conclusion that (b) was best - replace %% with ##.
Howard, Lori, Kin: Works for me.
Jon: Any objections?
Howard: Weak feeling that we should change to OpenSocial syntax.
Jon: The problem is with entityencode and escapequotes. We would probably want them on the outside, but Adobe already has implemented the @@ syntax with those functions on the inside.
Howard: Just think we need to address OpenSocial issues sooner or later, but not a critical requirement.
Kin: I would also like to see consolidation of syntax but we are coming up to a deadline, and any changes would have to happen now.
Lori: I vote for not at all
Howard: I don't have a strong preference
Jon: It is straightforward to add OpenSocial variable syntax in the future. Just one more transformation. We already differ on property substitution.
Howard: We might need to have a migration process in the future, but we can deal with it down the road
RESOLUTION: Localization substitution uses ## instead of %%
Finalizing the metadata spec
What implementation experience do we need? Detailed spec reviews: set a deadline? Target dates for finalization and approval?
Jon: Last week, without Kin, people said they wanted to wrap up the Metadata 1.0 spec but wanted to do a detailed spec review before finalizing.
Kin: I want to do a full review, also. But one thing I needed - the ability to insert content per instance of the widget. If not in 1.0, would do it on our end.
Jon: Don't we have that? I thought we talked about it.
Kin: Maybe using <require>? I'll review the archives.
Jon: How to do the final reviews?
Lori: Whole thing or in sections?
Kin: I like the section approach. We can all be reviewing the same things at the same times.
Jon: How much at a time? There are 3 widget chapters, overview, metadata and APIs. Is that too much for one week? The first chapters are Introduction, Widget Overview, Widget Metadata and Widget APIs.
Lori: How about first two chapters for next week?
Jon: Then in two weeks Widget Metadata, and the following week Widget APIs.
Jon/Lori: Similar pace for the rest of the spec
RESOLUTION: Final review of Chapters 1 (Introduction) and 2 (Widget Overview) next week, then following week is Chapter 3 (Widget Metadata), then following week is Chapter 4 (Widget APIs).
an odd object case
- Lori: http://openajax.org/pipermail/ide/2009q3/001208.html
- Jon: http://openajax.org/pipermail/ide/2009q3/001209.html
- Lori: http://openajax.org/pipermail/ide/2009q3/001210.html
Jon: How general is this case?
Lori: Good question. I don't know. Have to think about it. This widget I believe is from mootools.
Jon: My guess is that things are a little different with each different widget.
Kin: The big problem is with variable property names. Also, how to say 1-to-N number of entries. Should an IDE assume any number is allowed?
Howard: Don't try to do everything in v1. There will always be something we can't do and can add new features later. Simplification of specs is important.
Lori: I agree with keeping it simple, but Kin and I noticed the same issue independently.
Jon: We have extensibility mechanisms in the spec. You can add custom elements via XML namespaces and can add custom formats via setting 'format' to a URL.
Kin: In general I agree. We'll stick to 1.0 but where we need to extend we will use namespaces and propose enhancements into the next version of the spec
Jon: But before dropping the whole thing, how about indicating that the name is a variable by saying name="*"?
Lori/Kin: Solves part of the problem, a key part of the problem
Howard: Let's do that
Jon: But it is possible that a JS property will be named "*".
Howard: Not very common. We would need an escaping mechanism.
RESOLUTION: name="*" indicates property name is a variable. Need to figure out an escaping strategy to allow for case where there is a JS property named "*".
Older topics: 'target' on <library> and how to format dates
Kin: Two issues from a month ago: 'target' on <library> and how to format dates
Jon: I believe we resolved both
Kin: I'll look through the archives and send email if I see a problem
Kin: What about when a widget requires a date value in a particular format?