IDE Minutes 2008-01-31

From MemberWiki

Jump to: navigation, search




  • Jon Ferraiolo, IBM
  • Scott Richards, Adobe
  • Phil Berkland, IBM
  • Bertrand Le Roy, Microsoft
  • Marcos Caceres
  • Rich Thompson, IBM
  • Ted Thibodeau, OpenLink SW


Topic: Marcos introduction

Marcos: Here to help bridge between OpenAjax and W3C Widgets. Want to help collaborate as appropriate. Probably separate specs but work together where appropriate. I've done a lot of web work and am now working on a PhD on the technical challenges with widgets.

Jon: Marcos is an industry expert on installable widget technologies such as Dashboard, Google Desktop, Yahoo/Confabulator, Nokia widgets, MS Sidebar.

Topic: JSON Schema 'format' versus OpenAjax Metadata 'valueType'

Comparison matrix used for the discussion:

Rename 'valueType' to 'format'?

Jon: I like 'format' better than 'valueType'. Any other opinions?

Phil: 'format'

Jon: Any objections?


Jon: OK, it's 'format'.


Marcos: What's the use case?

Jon: For tools, can't think of a common use case. If someone needs to pick a filetype, then most of the time there will be a distinct list of possible filetypes expressed as an enumeration, which we support via a different mechanism.

Bertrand: Don't need it.

(decision: don't need a format type for mimetype)


Jon: Our use cases don't bundle binary data. I say we don't include anything having to do with images or attachments.

Rich, Phil: Agree.

Jon: Any objections to saying no to attachments?

(no objections)

date, time, millisecs

(Jon explains how we have Date due to ECMA-262 as a core JS type. Do we need a date format where the JS type is a string but the format describes the supported format for the string value?)

Jon: Is it sufficient to just use the JS type? A mashup tool will usually find a stored date value from a persistence mechanism, such as getting data from a server or from a cookie. This persisted value will almost always be a string. If we just have the JS type, then the tool would have to convert the string into a JS Date object first, and then the tool would use the JS Date object to bring up a calendar control or whatever.

MC: JS' Date is probably sufficient.

Rich: Yes. You want to leverage an existing standard. ECMA-262 provides that.

Bertrand: JSON Schema needs a string version of date because JSON does not support the Date type from JS. We don't need it because we have the Date type from JS.

Rich (after looking at quirks page on browser incompatibilities with Date.toString): We should encourage people to not use Date.toString and something more reliable, such as UTC.

Marcos: YUI calendar constructor accepts various formats. Lots of different options. Gets sticky.

Bertrand: Better for that case to describe values in a text description.

Rich: Another option to consider for date format is XML Schema Datatypes. If we want to specify a format, it is best to reference an existing spec rather than attempt to invent something ourselves. But using JS's Date makes sense for us.

Jon: Any objections to saying no to date and time?

(no objections)

Jon: Millisec. I would suggest we say no to that also. Just use an integer. Not common enough to warrant special treatment.

Scott: Just use an integer.

Jon: Any disagreement?

(no objections)


Jon: Same argument as Date. Therefore, we would say no. Any objections?

(no objections)


Jon: I originally said +1, but Bertrand pointed out complexity with different locales, and says -1.

Rich: The regular expression for capturing existing phone numbers is very complicated

Scott: I agree with Bertrand. Leave as a string, with an optional regexp to validate.

Jon: JSON Schema mentions E.123

Ted: E.123 doesn't address the complexity of the world today.

Rich: Yes, looking at the spec, it is attempting to define a standard which everyone should adopt in the future, not try to express the phone numbers that are used today.

Ted: Regarding convincing the world to change, lots of luck.

(resolution: say no to phone)

uri, url, urn

(discussion about what these terms mean. Also, iri.)

Ted: Probably should just go with string.

Rich: Agree.

Ted: The URI/IRI spec is constantly changing and growing.

Rich: Yes. It's value to us would be only in that it defines a handful of constraints, such as only one #

Ted: Maybe even that particular example isn't constrained. I think you have have more than one.

potential semantic value of 'format'

(we went on a tangent about whether 'format' could have value in expressing the semantics of the data, even if we didn't have a specific file format beyond string. we concluded that expressing semantics was a nice-to-have and we should push that off to the future.)

back to uri, url, urn

(resolution: no special format for uri, url, urn, iri, just use string)


Jon: JS has a Number, but no integer.

(some discussion, but inconclusive)

Jon: Let's start next week with integer, and then look at the remaining ones, such as CSS color, CSS length, and location. PHone call is on Tuesday next week.

Personal tools