IDE Minutes 2009 07-21

From MemberWiki

Jump to: navigation, search

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

Contents

Attendees

  • Lori Hylan-Cho
  • Kin Blas, Adobe
  • Javier Pedemonte, IBM
  • Jon Ferraiolo, IBM
  • Howard Weingram, TIBCO


Minutes

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.

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

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?

Retrieved from "http://www.openajax.org/member/wiki/IDE_Minutes_2009_07-21"
Personal tools