IDE Minutes 2009 07-28
From MemberWiki
URL: http://www.openajax.org/member/wiki/IDE_Minutes_2009_07-28
Attendees
- Lori Hylan-Cho
- Kin Blas, Adobe
- Jon Ferraiolo, IBM
- Javier Pedemonte, IBM
- Adam Peller, IBM
Minutes
(3) Older topics: 'target' on <library> and how to format dates
Kin was going to research the archives and see if his issues have been addressed
Kin: Have addresses the library issue and default for date, but when you enter the value into JS template, what format? Maybe need a date formatter.
Jon: Why not use one that is built into JS?
Kin: Are we saying that someone will have to code their JS into proper format? Realistic example: calendar widget as OAM. One of args to constructor is a date. How to format date, which might be @@mydate@@?
Adam: Date is a primitive object. Wouldn't you just serialize as a timestamp?
Jon: JS Date object
Kin: Value could be expressed in milliseconds from time zero...
Jon: OK. Or as a formatted yyyy/mm/dd
Adam: Wouldn't caller logic have to do this?
Jon: Some wrapper JavaScript within OAM layer
Kin: Your solution means you have to provide glue code in OAM file. We were hoping to provide a formatting option that wouldn't require glue code. This is the one we usually run into.
Lori: Let's work offline on a proposal.
Kin: OK
Kin: Do we want to have spec say there is a fallback if tool doesn't recognize a new function?
Jon: Tools MAY tell user "unrecognized function"
Kin: Dreamweaver probably would say "unrecognized function" and ask user whether to perform substitution without function or not perform substitution at all.
Jon: In that case, spec should say that implementation-dependent if unrecognized function
(no objections)
(1) Proposed escaping strategy for the 'name' attribute on <property>
Background on this is that we want name="*" to indicate that the property name is a variable. However, it is possible in JavaScript to have a property with the name of "*". Jon took the action to make a proposal. His proposal was to have the 'name' attribute on <property> require special processing. Developer tools must first check to see if name="*". If so, then that indicates that the property name is variable. Else, the property name may contain JavaScript escaping (e.g., \n indicates a newline character and \x20 indicates a space character) and developer tools must unescape the value of the 'name' attribute.
Actual write-up in the spec is at:
Jon: I had action to propose an escaping strategy. I proposed that we use JS escaping. Can't see what would be better.
Lori: Yes. Seems like an edge case.
Jon: OK with you?
Lori: Yes
Jon: Any objections?
(none)
(2) Content should use UTF-8 encoding
Spec link:
(Adam pointed out that XML takes care of encoding. Jon pointed to OpenSocial text that says <content> should be UTF-8. Jon points out that current spec text is about two cases that XML addresses.)
RESOLUTION: Remove UTF-8 section. Maybe add something else back in later if we can think of a case where encoding is problematic.
(4) Final spec review: Cover page
(Lori did detailed review and has proposed changes. Accept Lori's proposed changes. Lori to update spec)
(5) Final spec review: Chapter 1
(Lori did detailed review and has proposed changes. Accept Lori's proposed changes. Lori to update spec)
(Relative URI section accepted as is. OK to remove red-colored comment)
(6) Final spec review: Chapter 2
(Lori did detailed review and has proposed changes. Accept Lori's proposed changes. Lori to update spec)
(Kin suggested that we reorganize Overview section to break out "mashable" from other features. Jon said "mashable" is topics and APIs. Lori will reorganize things to have intro about "all widgets" or "basic widgets" and move mashup features into mashable widgets section.)
Next week: Widget Metadata chapter
Jon: Important chapter.
