IDE Minutes 2009 07-28

From MemberWiki

Jump to: navigation, search




  • Lori Hylan-Cho
  • Kin Blas, Adobe
  • Jon Ferraiolo, IBM
  • Javier Pedemonte, IBM
  • Adam Peller, IBM


(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

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?


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

Personal tools