IDE Minutes 2008-05-13

From MemberWiki

Jump to: navigation, search

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

Contents

Attendees

  • Jon Ferraiolo, IBM
  • Phil Berkland, IBM
  • Rich Thompson, IBM
  • Lori Hylan-Cho, Adobe

Minutes

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.

<include>

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.

Jon: Next topic is the proposed processing model. Here is what I would expect. You have file a.xml that has an <include> element that references a b.xml file. b.xml would have a root tag such as <includeFile>. What happens is that the <include> in a.xml gets replaced by all of the child nodes of the <includeFile> element from b.xml. This allows elements and text nodes. Simple, powerful, predictable, easy to implement, even in JavaScript.

Phil: Yep

<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.

Lori: Yes

Rich: Anything that is displayable to user and localizable must be an element

<topics>/<topic>

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?

(no objections)

'includeAssetReference'

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')

<widget> element

Jon: We are nearly done with widget chapter. Last element <widget> has some open questions.

'about'

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'

Lori/Jon: OK

'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.

'categories'

(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

Personal tools