IDE Minutes 2008-05-13
- Jon Ferraiolo, IBM
- Phil Berkland, IBM
- Rich Thompson, IBM
- Lori Hylan-Cho, Adobe
Try out Google Calendar invitations
Jon asks if it is OK for IDE WG to be guinea pig for using Google Calendar and sending invitations. Invitations should work just as they do now, using industry standard iCalendar format. One advantage is that there is a web site where everyone can see all of the OpenAjax meetings.
Everyone says it's OK to try out Google Calendar.
onchange/onChange proposal from Gadgets TF
Jon explains that the Gadgets TF has proposed that there be an onchangePattern attribute that is parallel with getterPattern and setterPattern and asks if IDE WG approves this.
Phil: OK with me
Lori: No opinion
Jon: OK, will assume this is OK and will update the spec
XML namespaces converted to JSON
Jon: There has been email about how to represent XML namespaces when the metadata is serialized to JSON. Manos points out that it's OK to use a colon as a property name so long as you use square bracket syntax, as in foo["a:b"]. Also, it will be common to have to use a for/in loop to get properties, and colons are OK for that. This seems like the obvious way to go.
Phil: Should be OK.
Jon: At our last phone call, we ended with Lori's proposal that lt;include> could be anywhere and works like server-side includes. That makes sense to me.
Phil: But what about validation?
Jon: The schema rules would show that <include> can be a child of anything. It seems to me that if you have an include mechanism, you will need to have a two-step validation no matter what. First, validate the original file that still has <include> in it. Then, perform the substitution and validate the result. No matter what rules you have, if you reference another file you have to verify that the referenced content is valid for the spot where the inclusion occurs.
Phil: I guess it's OK.
<title> element versus 'title' attribute for <property>
Jon: This is for the <property> element. Often a tool will present a property editor with the property names in the first column and property values in the second column. Sometimes the machine-readable property name is not good for user experience and it makes sense to provide a different short user-understandable string instead of the machine-readable property name. That's what 'title' is. We had decided that there would be a 'title' attribute, but the recent discussion about localization makes me thing it should be an element so that we can attach a localization key onto it.
Rich: Makes sense due to localization.
Jon: Also, for consistency with <description> and other similar things, which are elements.
Rich: Anything that is displayable to user and localizable must be an element
Jon: I changed the names from something like <pubsub>, <publishesTo> and lt;subscribesTo> to <topics>/<topic>, but this was never discussed, so I wanted to make sure everyone was aware of this change and approved it. Any objections?
Jon: Stew pointed out that this is a rather long attribute name. He suggested 'reference'.
Lori: We use 'reference'
Jon: OK with me, but I wanted to point out that the key semantic here is the active of including a <script> element or <link> element in the HTML.
(decision: call it 'includeRef')
Jon: We are nearly done with widget chapter. Last element <widget> has some open questions.
Jon: What was this attribute?
Lori: For us, it was the URL of a web page that provides about information for the widget
Jon: Sounds good to me. Does it hold either plain text or HTML like some of our other elements?
Lori: Just a URI
Rich: How about 'aboutURI'
'authorEmail' vs <author email='...'>
decision: drop 'authorEmail' attribute and leverage <author> element
decision: make some fields machine readable. Add 'email', 'organization', and 'website' to <author>. Text content has name of author plus anything else that isn't in one of the attributes and should be presented to user.
(discussion, mostly unminuted. this is metadata that allows a tool to place a widget in different sections of its UI for when there are lots of widgets that can't fit on a single palette)
Lori listed some categories in Dreamweaver, which included common, layout, Spry, data, text
decisions: Have <categories>/<category> elements. Using elements allows category names to have localization keys. Define a standard set of categories which tools are expected to localize. Extensible custom category names use QNames and require localization by the metadata provider. More than one category can be provided for a widget
ACTION: Lori to send an email with information about Dreamweaver categories
ACTION: Jon to make a wiki page that shows various categories from various products and Ajax toolkits