[OpenAjaxIDE] Today's meeting minutes

[Bertrand Le Roy]

IDE Minutes 2007-12-20
>From MemberWiki
Jump to: navigation<http://www.openajax.org/member/wiki/IDE_Minutes_2007-12-20#column-one>, search<http://www.openajax.org/member/wiki/IDE_Minutes_2007-12-20#searchInput>

URL: http://www.openajax.org/member/wiki/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>
Minutes

Jon: today, data type issue

http://www.openajax.org/member/wiki/IDE_Issues

http://www.openajax.org/member/wiki/IDE_Issue_7

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.

http://www.openajax.org/member/wiki/IDE_Issue_7_Existing_Practice

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.

Bertrand: that description can be a transformation function, maybe javascript.

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?

Jon: yes

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.

Jon: now for enum, which is not a core javascript type but is common enough.

Bertrand: maybe there is again an underlying type and allowed values.

Jon: could be specified by an associative array.

Jon: location

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.

Jon: duration?

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?

All: ok.
Retrieved from "http://www.openajaxalliance.org/member/wiki/IDE_Minutes_2007-12-20"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20071220/392f567e/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 50 bytes
Desc: image001.gif
Url : http://openajax.org/pipermail/ide/attachments/20071220/392f567e/attachment-0001.gif