[OpenAjaxIDE] Minutes 2009-07-21

Jon Ferraiolo 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

URL: http://www.openajax.org/member/wiki/IDE_Minutes_2009_07-21


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:

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

Howard: Good

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.

Lori/Howard: Yes

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

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

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...
URL: http://openajax.org/pipermail/ide/attachments/20090721/be1a16f4/attachment.html 

More information about the IDE mailing list