IDE Minutes 2008-01-24

From MemberWiki

Jump to: navigation, search




  • Jon Ferraiolo, IBM
  • Scott Richards, Adobe
  • Stewart Nickolas, IBM
  • Phil Berkland, IBM
  • Ingo Muschenetz, Aptana
  • Bertrand Le Roy, Microsoft
  • Krip Zyp, Sitepen


Topic: Shift time of the meeting?

Marcos is in Australia. Can we shift the time? No Europeans now, so probably OK. Jon to send email to group asking about it.

Topic: Properties and Datatypes

Jon: Let's go through the JSON Schema vs OpenAjax Metadata table row by row.

Jon: There have been multiple emails where people said it doesn't make sense to unify JSON Schema with OpenAjax Metadata, but we should attempt to coordinate and align where it makes sense.

  • "name" attribute: "Tentatively Approved"
  • "type" attribute: "Tentatively Approved", but we need to talk about what goes inside this attribute, which takes us to the "Datatype" discussion.

Topic: Datatypes

Jon: Important to unify the datatypes between JSON Schema and OpenAjax?

(someone said yes, but only need to unify where there is overlap. JSON Schema is about the JSON subset of JS, which only contains 5 datatypes, whereas we need to address the full language.)

(background note on this discussion: OpenAjax is proposing the datatypes from the ECMA-262 spec, where the types have a capitalized first letter, such as "String". JSON Schema is proposing only the 5 datatypes from JSON, plus "any", plus one or two other things, with lowercase first letter, as in "string")

Bertrand: JSON Schema can use what typeof returns, but we have to deal with more complicated issues. Would like JSON Schema to use the ones that we have.

Jon: OK, more complex, but could you explain how.

Bertrand: We have to support more complex types.

Jon: Like RegExp?

Bertrand: Yes, but also complex types. We don't have the recursive typing capabilities that JSON Schema has. Also, JSON Schema deals only with pure data.

Jon: Yes, we also have to include functions, regexp, etc. Also, typeof only returns a subset of JS types.

Bertrand: JSON only has five basic types. Maybe we can accept both the lowercase and uppercase versions.

Bertrand: Need to look at the new datatypes for HTML5.

(discussion about how solid the HTML5 spec is and the timing of when it might come out)

Jon: Need to do due diligence on what HTML5 is doing.

Ingo: It is safe to stick to the ECMA spec.

Bertrand: Any is useful. In what we are doing, if you don't specify a type, it is any.

Phil: I would prefer a list of types usually, but eventually that won't cover all cases.

Jon: Any as the ultimate default makes sense in a dynamic language like JS.

Ingo: If no return type is specified, would the default be "any".

Bertrand/Phil: Yes.

  • "any": Include (tentatively approved)
  • "void": Include (tentatively approved)
  • list of datatypes: Include (tentatively approved, but still need to discuss quoting)

Phil: Not sure how useful "Undefined" is. More of a runtime thing.

Jon: Yes, I was thinking that, too.

Ingo: OK to remove.

  • "Undefined": Remove (tentatively approved)

Bertrand: For list, what is the syntax

Jon: Array of quoted strings

Bertrand: Maybe remove the quotes

Phil/Ingo: The quotes are problematic for XML

Jon: OK, remove the quotes

  • list of datatypes: Include, but remove quotes (tentatively approved)

Jon: What about Function, RegExp, Date and Error?

Bertrand: Error makes sense. We have functions that return it.

Phil/Ingo: Yes, include it.

  • "Function": Include (tentatively approved)
  • "Date": Include (tentatively approved)
  • "RegExp": Include (tentatively approved)
  • "Error": Include (tentatively approved)

Phil: With Function, we could include params and return type if we were ambitious.

Jon: How about we tentatively approve function, but leave in a note about possibly being more ambitious in the future?

Phil: Yes

Jon: What about the proposal of allowing both UC and LC versions of the 5 datatypes from JSON Schema?


  • Add 5 more known strings and thus support both String/string, Number/number, Boolean/boolean, Array/array, Object/object: (tentatively approved)

Jon: Let's discuss 'valueType' and 'format'. Both seem to be providing extra information about the data that could be used by software agents. Kris, what's the objective with 'format' and current status?

Kris: Lots of discussion back and forth. For JSON Schema core datatypes, we are thinking the 5 core types , and thinking about integer. Format would be extra information for datatypes that use "string", such as date/time, mimetype.

Bertrand: What is extensibility story?

Jon: Yes, for conflict prevention? We are using QNames or reverse domain syntax ( to prevent conflicts with custom types.

Kris: Still thinking about that.

Jon: What's the purpose of 'format'?

Kris: Similar to what you are doing with 'valueType'. To help tools do things.

Jon: I suggest that we don't require ourselves to unify 'valueType' and 'format' at this point, but look at it again once both efforts get further along. Regarding 'valueType' in our spec, let's table it until next week so we all have a chance to think about it some more. Back to the attributes at the top of the table.

  • default: include (tentatively approve)

Jon: required="true" vs optional="false".

Scott: What does required mean? If a value has not been provided, then you must use the default, or that a value must be provided?

Jon: My understanding is that a value must be provided.

Scott: Would all permutations of required=true|false and default=whatever be allowed?

Jon: I would think so. But we need to define ultimate defaults for each possible datatype.

Scott: Our goal is to make widgets as easy as possible. Go with default.

Jon: So, 'required' means use SHOULD provide a value, and tools MAY choose to report an error if a value is not provided, but there MUST be an ultimate default for each datatype.

Stew: Applies to constructor?

Jon: What the spec says is that the tool should pass any properties that do not equal their default, so the burden on the constructor is to set defaults for any properties that are not passed to the constructor.

Personal tools