IDE Minutes 2008 07 29
- Kevin Hakman, Aptana
- Lori Hylan-Cho, Adobe
- Kin Blas, Adobe
- Jon Ferriaolo, IBM
- Wayne Vicknair, IBM
- Rich Thompson, IBM
- Phil Berkland, IBM
- Bertrand Le Roy, Microsoft
Wayne's group has been doing some implementation; they've got a lot of code up.
News: Lori's going to Aptana; Kin will represent Adobe starting on the 12th.
Enums and Options
What to do about ugly nesting?
Jon's proposal is to make <options> and <enums> optional, just like all other plural elements. If the plural tags are missing, default values for any attributes that would normally be specified for <options> would apply.
Approved by vote of silence.
Valid parents, then, of <option> would be <options>, <enum>, <property>, (also <parameter>?).
Jon did an inventory of all the elements and attributes to see where locid applied and found that by coincidence, the elements or attributes that take plain text or HTML also had the locid attribute. One exception is the label attribute on the <option> tag; Jon's proposal is to allow a <label> subelement as well as a label attribute. The former would take a locid attribute indicating that the contents should be localized.
Kin suggested that the fewer the variations, the better; he's in favor of a <label> subelement only and no label attribute. Approved by vote of silence.
Next issue is <category>. Debate about whether we need localizable category names; we decided that machine-readable is the way to go because the tool may already have a localized value for an existing category, and how would conflicts be resolved if several widgets all said they belonged to the same machine-readable category but provided different translations of that category?
Rich is going to look into the directoryTitle attribute and see what we need to do with that.
Rich: The title is what's placed on the mashup canvas, and directoryTitle is what's placed in the content directory.
Jon: I would conclude from that that directoryTitle should be an element.
Src and Target attributes of <required>
Kin: Rather than have a variable, have the path be relative to wherever the library is.
Bertrand: If it's relative, the IDE should be able to infer the path to the file.
Jon: The the rule could be that if there's a library attribute (e.g., library="dojo"), then target is relative to wherever the dojo library got instead. But then we need a library attribute.
[Discussion over whether we already had a library attribute (no) and whether library would make copy unnecessary (yes).]
Jon is not loving the lengthy filenames that result from appending _OpenAjaxWidget.xml, _OpenAjaxAPI.xml, etc.
Discussion about whether to use .oam or _oam.xml as the filenaming convention. Concerns over .oam not being recognized by operating systems or web servers. Consensus was to go with .oam.xml.
How then to differentiate between widget metadata and library metadata, since library metadata may need to be loaded first. Jon proposes .library.oam.xml for the library file. Approval by silence.
Jon's coded a form that allows upload of an XML file, which is then validated with Jing (sp?). For a widget developer, passing validation would be all that's necessary to say they've passed the InterOperability tests.
Jon plans to add the ability to point to a metadata file via URL rather than uploading.
[Lori tried uploading a metadata file for validation and got an error; will have to figure out what's wrong there. :-)]
Jon working on more InterOp tools, as are the guys from IBM Austin.
Goal is to have InterOp complete by AjaxWorld in October; press releases and possibly an event with participating companies will happen around that time.
Do we agree that the description of <seealso> in the spec is accurate?
Do we want to allow multiple <seealso> elements?
Bertrand: That was the idea in proposing it as separate from <see>.
Jon: If we're going to have a plural, should we go with Aptana's names <references> and <reference>?
Kin, Lori, and Bertrand: YES. (All of us hated <seealsos>.)