[OpenAjaxIDE] Minutes 2009-07-21
jferrai at us.ibm.com
Tue Jul 21 14:40:52 PDT 2009
Minutes from today.
I have updated the spec per our two resolutions: (a) %% becomes ##, (b)
name="*" indicates a variable property name.
I'll send another email soon about name="*".
IDE Minutes 2009 07-21
Any products out there with %% localization support already?
Jon: http://openajax.org/pipermail/ide/2009q2/001196.html Jon:
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:
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
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
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
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
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
Lori: I agree with keeping it simple, but Kin and I noticed the same issue
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
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
Older topics: 'target' on <library> and how to format dates
Kin: Two issues from a month ago: 'target' on <library> and how to format
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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IDE