[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





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

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