IDE Minutes 2009 06-16
- Lori Hylan-Cho
- Camilia Delbrin, Adobe
- Javier Pedemonte, IBM
- Jon Ferraiolo, IBM
- Bertrand Le Roy, Microsoft
- Kin: http://openajax.org/pipermail/ide/2009q2/001113.html
- Jon: http://openajax.org/pipermail/ide/2009q2/001114.html
- Bertrand: http://openajax.org/pipermail/ide/2009q2/001115.html
- Jon: http://openajax.org/pipermail/ide/2009q2/001117.html.
- Jon: http://openajax.org/pipermail/ide/2009q2/001118.html.
- Jon: http://openajax.org/pipermail/ide/2009q2/001134.html.
=> format="style" and format="length" accept any value that would be valid within an HTML doc? => Ignore constraint attributes if 'format' is specified? => Add format="uri"? => Add other format types from Lotus Mashups? (http://www-10.lotus.com/ldd/mashupswiki.nsf/dx/working-with-data-types)
Jon: Kin asks about what happens if you combine @format with constraint attributes, such as 'minimum' and 'maximum'. I propose that if @format is there, then the constraint attributes are ignored. Too many special cases. Let's keep it simple for implementers. What do others think?
Lori: The <title> element could suggest constraints, but not do anything automatically. Ignoring constraints would reduce complexity.
Jon: Any objections?
RESOLUTION: If @format has a value, then ignore constraint attributes.
Lori: Some don't have specs.
Jon: Yes, such as address.
Lori: Even without a spec, this is information that provides a suggestion to the tool about what this value means.
Jon: A standard set of semantically rich types is very valuable in mashup scenarios. It is critical information to allow a mashup tool to link message publishers with message subscribers and to link shared properties.
RESOLUTION: Subsequent phone call to review the list of proposed built-in types one by one
(2) Change sharedAs="propname" to shared="true|false"
- Jon: http://openajax.org/pipermail/ide/2009q2/001123.html
- Howard: http://openajax.org/pipermail/ide/2009q2/001125.html.
(Howard says "Okay.")
Jon: We don't have an alias feature for topics. I'm trying to simplify.
Javier: My only concern is that now people will have to namespace their property names. Better to have an internal property name that's simple but share with a namespaced property
Jon: Which would you prefer?
Javier: shared=true is simpler, but I would lean towards keeping sharedAs. Both have merits.
Jon: Doesn't sound like we feel there is a compelling reason to change, and argument to keep. Any objections to leaving it as is?
RESOLUTION: Leave 'sharedAs' as is.
Jon: I'll make sure Howard is OK with this.
(3) Clarifications on hidden, readonly and designonly attributes
* No runtime enforcement of hidden, readonly and designonly * hidden="true" - property does not appear in property editor dialogs * readonly="true" - property appears in property editor dialogs, but cannot be edited there * designonly="true" - property is available in "design-time" property editors, but not run-time property editors. This is meant for configuration properties where an admin configures a generalized widget, such as setting the RSS address for a feed widget, whereas perhaps "font-size" might be a run-time property that an end-user might configure.
Jon: I just wanted to make sure that everyone was on the same page. Does anyone see any problems with the above summary?
(4) <library> and the @target ...
- Kin: http://openajax.org/pipermail/ide/2009q2/001129.html
- Jon: http://openajax.org/pipermail/ide/2009q2/001133.html
QUESTION #1: Does the @src path for a <library> tag always have to end with a name of a directory? Jon: I propose that we add a clarification to the spec that the 'src' attribute can point to either a directory or a file. QUESTION #2: Shouldn't the <library> tag allow for the specification of a @target attribute? Jon: I propose that we add @target to <library>. QUESTION #3: Is @target allowed on <require> elements that are children of a <library> tag?? Jon: I propose that we allow @target on <require> elements that are children of a <library> tag. QUESTION #4: If we allow @target on <library>, should we allow @target on any of its child <require> elements? Jon: Given my proposals for #1, #2 and #3, then yes.
Jon: I suspect that my answers are what Kin wanted to hear.
Camilia: Your answers were what we wanted. We submitted these questions mostly to clarify.
Jon: Anyone disagree?
Lori: I'm cool with that.
RESOLUTION: @target changes as described above.
(5) Allowable units for 'width' and 'height' on <widget>
* Integer values only, or any CSS length value?
Jon: I think everyone agrees with leaving off absolute unit specifiers, such as en, em and pt. Question about percentages, such as the width should be 50% of the canvas.
Lori: Like HTML tables, where values can be either pixels or percentages.
Jon: Javier, you are implementing this. What do you think?
Javier: Let's keep it simple. I prefer just integers. Haven't seen a use yet for percentages.
Jon: We aren't painting ourselves into a corner. We can add percentages in a subsequent version of the spec.
Lori: I prefer integers only. 80% of content won't use it, but I worry some that percentages will be more popular than we think.
Jon: Any objections to integer only?
RESOLUTION: @width/@height on <widget> must be integers
(6) jsClass and Widget APIs - optional or required?
* What about widgets that only work if the environment supports jsClass and Widget APIs? * Perhaps add a new attribute, widgetAPIs="required|optional"?
Jon: As I was proofreading the spec, it struck me that some widgets might use APIs, but IDEs might not support the APIs, and we don't want things to break. How does a tool such as an IDE distinguish between widgets that require API support and widgets that don't?
Lori: Tool has to invoke constructor and onload for this type of widget to work.
Javier: But also what if widget has changed size? Should IDE include logic to manage widget size?
Lori: IDE should only have to be responsible for putting things onto the page out of the XML.
Jon: Question is where we draw the line between standalone widgets and mashable widgets. Maybe 'jsClass' attribute. If you specify that attribute, then you are saying you required Widget API support.
Javier: Yeah. An IDE can look for jsClass, and if in file, then can tell user it cannot support that widget.
Jon: If so, then we don't need my suggestion about a new widgetAPIs attribute because jsClass serves the purpose.
RESOLUTION: if jsClass attribute exists, then the widget requires support for Widget APIs.
(7) getterPattern and setterPattern for widgets?
* Drop getterPattern and setterPattern for widgets?
Jon: As I was proofreading the spec, I saw getterPattern and setterPattern on the <widget> element, and this didn't make sense to me. On the widget side, you don't specify the names of the functions for getters and setters, and instead you manage properties via onChangePropname, getPropertyValue and setPropertyValue. Anyone see how these attributes make sense for widgets?
Lori: I'm trying to picture a requirement. Bertrand was very involved in this. Bertrand, does this apply in widget scenarios or only in API scenarios?
Bertrand: I haven't thought about widget scenarios.
RESOLUTION: Remove getterPattern and setterPattern from widget side until someone finds a scenario for these attributes. Only apply to JS API use of properties.
(8) <enum> for widgets?
* We have <config> and <enum> on the JS APIs side, but only <config> on the widget side.
Jon: I noticed what looks like an inconsistency. JS APIs support <config> and <enum>, which are both named things that a 'datatype' can refer to. But widget side only supports <config>.
Lori: How would it be used with widgets?
Jon: As a named, reusable set of <options>.
Lori: Seems logical to me. Something we would want to do.
Jon: Javier, you are an implementer.
Javier: I don't know about this one. I didn't code this part of the spec.
Jon: Seems like a small change versus inline <options>.
Lori: My inclination is to add it.
RESOLUTION: Add <enum> to widgets
(9) Specification sections to review
(Jon points out some new sections of spec where color-coded resolutions were converted into spec text and asks if anyone sees any problems)
(10) Nested <properties> elements
- Kin: http://openajax.org/pipermail/ide/2009q2/001143.html
- Jon: http://openajax.org/pipermail/ide/2009q2/001150.html
Lori: I'm for the naming approach rather than the nested properties approach. It does collide with nesting approach we already have. I see you prefer dot syntax versus ::. Any downsides to dot syntax? How about slash?
Javier: I agree with the naming approach.
(everyone assumes Kin proposed :: to prevent potential conflicts where the 'name' attribute might have special characters such as foo/bar or foo:bar or 1.2.)
Jon: Maybe the double-colon approach is reasonable
Lori: I'm OK with it
Jon: Any objections to double colon approach?
RESOLUTION: Add note to spec that talks about the naming convention where :: implies subtabs
(11) Default values for Date type on <property>
- Kin: http://openajax.org/pipermail/ide/2009q2/001142.html
- Bertrand: http://openajax.org/pipermail/ide/2009q2/001144.html
- Jon: http://openajax.org/pipermail/ide/2009q2/001145.html
- Adam: http://openajax.org/pipermail/ide/2009q2/001146.html
Javier: Does anyone remember why we decided to make 'defaultValue' required?
Jon: To avoid syntax errors. Force the widget developer to provide a default value that works for the given datatype.
Lori: Also, for factory methods which take an object literal, you would need to know all of the fields in the object literal.
Javier: But if we have a reasonable default for each type, then we don't need to make defaultValue a required attribute
Lori: That sounds right
Lori: In object literal case, there will usually be a default value in the XML
Javier: Already handling. For some, might as well do it for all and make it optional.
Lori: Makes sense.
(12) date formats allowed
Jon: I said YYYY/MM/DD, Adam suggested ISO dates, which are in early versions of ECMA5 spec, but not supported yet by browsers.
Bertrand: I was surprised that browsers did not support this.
Adam: Would require a shim today.
Bertrand: Are we talking date or date/time?
(out of time. resume discussion on this topic next week)