IDE Minutes 2008-02-05

From MemberWiki

Jump to: navigation, search

URL: http://www.openajax.org/member/wiki/IDE_Minutes_2008-02-05

Contents

Attendees

  • Jon Ferraiolo, IBM
  • Lori Hylan-Cho, Adobe
  • Phil Berkland, IBM
  • Bertrand Le Roy, Microsoft
  • Rich Thompson, IBM
  • Ted Thibodeau, OpenLink SW
  • Ingo Muschenetz <ingo@aptana.com>
  • Stewart Nickolas, IBM

Minutes

(continuing to walkthrough the wiki page at:

)

Jon: We left off last week with 'integer'.

'integer'

Jon: Tools would want to distinguish between Number and integer

Lori: Agree

Rich: Agree as well. We should be careful to pick things from the table. After looking at the current table, my conclusion was only support integer and extensibility. We can define other types via OpenAjax-defined extensions.

Jon: If the only format we have is 'integer', then we should just have an 'isInteger' attribute.

Lori: Are we going with a core set of basic types which are fallbacks for optional extended types?

Jon: We have talked about these formats as being optional with fallbacks to a core type.

Phil/Lori: I don't think tools should be required to support these formats.

Ingo: We ought to specify a fallback for all cases.

Rich: Yes, we have to have a fallback.

Jon: I think we should make integer into its own boolean attribute. All of the other formats will fallback to string.

Bertrand: That's what we do.

Lori: Make sense.

Tentatively approved: Define a new boolean attribute for integer

'color'

Bertrand: Just use the CSS color definition

Jon: Probably CSS 2.1

Jon: Do we want to support the full CSS syntax for flexibility or a restricted syntax, such as an RGB triple

Lori: Prefer the flexibility

Bertrand: Most tools have CSS parsers. As a web developer, I want to carefully say 'orange' so it gets passed through as is. Most implementations will just pass the value into the web page.

Jon: I'm sold.

Stew: I agree. Good alignment with goal of skills transfer.

Tentatively approved: Support format='color', where the value matches CSS2.1 <color>

'length'

Jon/Bertrand: Same argument

Tentatively approved: Support format='length', where the value matches CSS2.1 <length>

'style'

Rich: Some tools have style editors

Lori: I'm not sure about the value above just using a string.

Rich: There are style editors and there is a fallback to string.

Jon: I think that's a good general criteria for making decisions. If some tools have special editors for the format and if there is a reasonable fallback of typing the syntax as a string, then we say yes.

Tentatively approved: Support format='style', where the value is a CSS style declaration

'class'

Bertrand: Our product looks at the list of classes used

Lori: Us, too

Tentatively approved: Support format='class'

'location'

Jon: From Google Gadgets. Lat/long pair.

Ingo: ISO 6709, also adds altitude

Stew: The name 'location'. I think about URL location. Better to have a name that refers to geospatial location.

Jon: A tool could present a map as a custom editor. Stew, would a mashup tool need this?

Stew: I wouldn't recommend it as a core format.

Ted: There are geoname antologies. Assigns a unique ID to a particular location.

Jon: Therefore, not a core type. Use extensibility to define an OpenAjax type.

Lori: Yes.

Tentatively approved: 'location' (or whatever) is not a core type. Probably want to promote something in this space via extensibility.

Extensibility

Jon: 3 common approaches: XML namespace prefixes, reverse domain syntax, and a URI.

Ted: Namespaces are shortcuts to URIs. Therefore, just using URIs is a simpler approach.

Rich: URI allows for something at the destination, such as help information.

Jon: For Hub 1.0, we choose reverse domain syntax. This might have been core with the recursive topic algorithm, but my memory is fuzzy. (After the phone call, the answer is that a period is the token separator in event names, and we recommend reverse domain syntax to avoid event name conflicts.)

Ted: But this is a different technical space.

Jon: URI sounds good to me. But how does a tool distinguish between built-in types and extensions using a URI?

Rich/Ted: Something you don't recognize is treated as an extension.

Tentatively approved: URI syntax for extensibility

'email'

Ted: Think not.

Jon: We actually discussed this previously and said no. Just use string.

Tentatively approved: Don't define a format for email.

'address'

Jon: We discussed this one previously also.

Tentatively approved: Don't define a format for address. Maybe reference a microformat via extensibility.

Jon: OK, we finished the table at the bottom. Let's resume looking at the table at the top.

'arrayType'

Rich: Alternative approach is type='[element-type]'

Rich/Stew/Lori: Like the square bracket approach

Tentatively approved: Get rid of arrayType. Add bracket syntax to 'type', with element type inside the brackets

'required' vs 'optional'

Jon: I believe Kris wants optional because you want the default to be false, like a numeric having a default of zero.

Rich: Agree that the default should be false. In our case, most of the time properties are optional. Therefore, we would prefer an attribute named 'required' with default false.

Tentatively approved: Use 'required', not 'optional'

'nullable'

Jon/Bertrand: From JSON Schema, but we allow a list of types, with Null as one of those types. It's nullable if it lists Null as a possible type.

Tentatively approved: We don't have a 'nullable' attribute

'unique'

Jon: From JSON Schema. Makes more sense there because they are trying to represent data, and some data fields need to be unique, such as product id.

Rich: Only makes sense if tool would have multiple instances of the same component

Bertrand/Rich: Can happen but not very often

Tentatively approved: We don't have a 'unique' attribute

'min' and 'max'

Jon: I am proposing an overloading approach where min/max for numbers expresses a range, but for strings it is min/max number of characters, and for array is min/max number of elements in the array.

Bertrand: What about date?

Jon: Good point.

Rich: Do we have a constraint system?

Jon: Not now. In previous discussion, we talked about an approach where common things were simple. I came up with a proposal that I hoped matched our previous discussion.

Rich: My preference would be a constraint system, but only support simple things but allow extensibility. Perhaps only constraint that is built in would be min/max.

Ted: For arrays, some confusion whether min/max applies to the array size or to the values in the array.

Jon: Yes.

Jon: Out of time. Let's resume with min/max at next call, Friday Feb. 15.

Personal tools