IDE Minutes 2007-12-20
Attendees this week
- Jon Ferraiolo <jferrai(at)us.ibm.com>
- Lori Hylan-Cho <lorihc(at)adobe.com>
- Ingo Muschenetz <ingo(at)aptana.com>
- Ted Thibodeau <tthibodeau(at)openlinksw.com>
- Bertrand Le Roy <Bertrand.Le.Roy(at)microsoft.com>
Jon: today, data type issue
Jon goes through his proposal.
There are several efforts across the industry that contain data types (JSON schema, Google gadgets, etc.).
We talked about custom property editors, regex validation, changed events, and extensibility.
Merged the type attributes (jsType is gone)
Two categories of data types: supported by all and custom (optional). There are fallbacks for all custom.
Bertrand: why are things like date, length and color optional?
Jon: low bar for interop. People can invest a small effort and be interoperable.
Ted: There has to be a description of the transformation.
Jon: what about IDEs that are not js?
Bertrand: JS is the lingua franca for all we're doing here so it looks like the best candidate.
Ingo: how did you determine the core?
Jon: I looked at the js types
Ingo: Ecma has date and regex that are not included
Bertrand: one criterion for the core types is types that already have a common standard, it's the case of date, color, length.
Jon agrees that's a possibility
Ingo: subtyping can be handled by validation. Any suggestion on how we handle arrays? How do Microsoft's xml comments handle arrays?
Bertrand: we have type="Array" elementType="Number" for example for a number array, to handle the most common cases. It's been very useful. There are configurations that we're not handling (i.e. arrays of arrays) because that becomes too complex quite fast but this pragmatic approach works for the most common cases.
Jon: pushes back on CSS types that are very complex to handle
Bertrand: most web IDEs probably already have those
Jon: some might not
Bertrand: ok with the fallback from those
Jon: how are custom data types specified? There is a need for a QName approach.
Ingo: is the first part of the qname what was declared in the registry?
Lori: is the first part referencing the toolkit or the ide?
Jon: there would probably be a mapping somewhere between the js types and those qnames
Bertrand: why don't we use fully qualified names (namespace.type)?
Ingo: what about people who don't use namespaces?
Bertrand: Is that really common? Maybe they alias to a unique name.
Jon: to summarize it would be dojo:type or dojo.type ([global object defined in the registry].type) We need to think about that some more. We all agree that if you use a custom type it should be qualified.
Lori: what about a css selector type?
Jon: it's a string
Bertrand: the ide could provide some help building that string
Lori: the ide could scan the document to provide help
Bertrand: it's like a subtype, again
Jon: like an idref in xml
Jon: similarly, element ids are string that should have helpers
Bertrand: maybe the type and editor are two orthogonal pieces of information
Jon: that is similar to the old xsdtype and jstype except here type and editortype.
Jon: let's go through the list and see which approach makes the most sense.
Jon: type names should be first letter capitalized
?: not sure about "any".
Jon: how do you represent multiple possible types? object doesn't work.
Bertrand: maybe taking multiple types is common enough that we capture it by allowing type names separated by commas.
Jon: yes, we could get rid of "any".
Jon: let's look at numeric types.
Bertrand: we probably don't need the whole range of numeric types. What we've been doing is keep just Number but add the information that something is integer by adding just a bool in addition to the type. Add range validation to that and you pretty much cover all requirements.
Bertrand: maybe there is again an underlying type and allowed values.
Jon: could be specified by an associative array.
Bertrand: uneasy about singling out Google. There must be a standard way of decribing location.
Jon: probably several. Need to research.
Ingo: ISO6709 specifies lat, long and altitude.
Jon: goes through the list, time is in CSS but not in much use
Bertrand: how about looking at xml schema?
Jon: there's got to be an iso spec for time. I'll look into that. Should we have time?
Lori: ambiguous. What is it? Time of day?
Jon: absolute time of day.
Lori: call it time of day. Is it common?
Ted: datetime is common, not time.
Bertrand: Date is enough.
Bertrand: yes, forget that too
Jon: other extended types?
Bertrand: address and other types are going to be defined by many people differently from whatever we come up with
Lori: e-mail is useful
Bertrand: e-mail is ok, but address, phone and others are cans of worms
Jon: let's drop them
Jon: let's drop binary too
Jon: rich text could be a hint, a supplemental attribute, like mimetype.
Jon: how about we start translating that into a draft spec and start putting green light over sections of it?