IDE Minutes 2008-05-29

From MemberWiki

Jump to: navigation, search

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

Attendees

  • Kevin Hakman, Aptana
  • Jon Ferraiolo, IBM
  • Phil Berkland, IBM
  • Rich Thompson, IBM
  • Lori Hylan-Cho, Adobe
  • Bertrand Le Roy, Microsoft
  • Stew Nickolas, IBM

Minutes

Jon: I sent the following email and recapped it for us:

We agreed several weeks ago that we should reorganize the spec so that elements that are shared across both main chapters (i.e., APIs and Widgets) are not defined redundantly. My proposal is below.

What we have now is:

  • Chapter 1: Introduction
  • Chapter 2: Widget Metadata
  • Chapter 3: API Metadata
  • Chapter 4: Library Metadata (very small)
  • Chapter 5: Datatypes
  • Chapter 6: Localization

Here is my proposal:

  • Chapter 1: Introduction
  • Chapter 2: Widget Metadata
  • Chapter 3: API Metadata
  • Chapter 4: Library Metadata (very small)
  • Chapter 5: Properties
    • <properties>/<property>
  • Chapter 6: Datatypes
    • Existing content, plus <enum>, <options>/<option>
  • Chapter 7: Topics
    • <topics>/<topic>, 'publish', 'subscribe', 'topic'
  • Chapter 8: Descriptive elements and attributes
    • <description>, <title>, <remarks>, <examples>/<example>, <authors>/<author>, <icons>/<icon>, <license>, <see>/<seealso>
  • Chapter 9: Compatibility elements and attributes
    • <available>, <deprecated>, <useragents>/<useragent>
  • Chapter 10: Inclusion
    • <include>
  • Chapter 11: Localization

We might need another chapter or two having to do with features needed by the Gadgets TF, such as one or more chapters on the lifecycle of a mashup widget and their APIs.

Discussion on the above:

>> Kevin: What's in Section 4?

>> Jon: A few tags to describe a library like dojo, its version, etc…

>> Kevin: seems fine to me. Any objections to Jon's proposed outline?

>> Silence

>> Consensus: OK


Discussion of Lori's email with >> comments/discussion interspersed between her - lines….

- Under <widget>, did we decide on "about" or "aboutUri" as the name of the attribute that points to a page describing the widget and its use?

>> Jon should be about Uri. I'll change that.

- I can't remember why we needed separate specVersion and widgetVersion attributes for the <widget> tag. Why can't we just use version to indicate the version of the widget? It seems like any spec version should be listed in an XML declaration, if necessary.

>> Lori: people might be confused between the spec version and the widget version.

>> Proposal: <widget version=[widget version number] spec=[oaa spec number]>

>> Consensus: OK. :-)

- It looks like we never came to resolution on scaling and scrolling as <widget> attributes. They're apparently Gadget requirements.

>> Discussion of the semantics of scrolling and scaling with Lori and Stu.

>> Consensus: scrolling= false is the default and it's a boolean. false means the canvas does it.

>> scaling += preserveAspect is added as a potential value.

- For the <category> tag, I was supposed to supply the list of built-in Dreamweaver Insert bar categories. They are: Common, Layout, Forms, Data, Spry, Text, Favorites, ASP, CFML, CFForm, JSP, and PHP. Insert bar categories in Dreamweaver are extensible, so more can be added at any time. - Was the value of the <category> tag supposed to be its contents? What is the value of the localizationKey attribute supposed to be?

>> Jon: I'll create a wiki page for this. Goal is to see if there are common category subsets.

>> Rich: Not just terms, but also the semantics should be on the wiki

>> Lori: What is the value of the category tag?

>> Group discussion of attributes.

>> Jon: proposal name=[list of categories]

>> Consensus: OK


- I know that we'd intended to share the <authors> and <author> tag with the API metadata, but currently the information in the two specs is different. The API version has all information appearing in either plain text or HTML as the content of the tag. The widget version has separate email, organization, and website attributes, but no attribute for name.

- Speaking as the person who would have to write the code to collect author information from this tag, I'd prefer to have the various bits of information available in specific attributes. I have no objection to supplemental information, logos, or whatever to appear as the content of the tag, but in order to make sure that the proper information gets plugged in where we need it to go, attributes make more sense to me.

>> Lori: odd that name is the content of the node with attributes for email, etc…

>> Stu: we did some work on this in the Gadgets WG.

>> Jon: Many of these new ones are from Google Gadgets so that we can map to/from Google Gadgets without loss of data.

>> Jon: What I'm hearing is that for <authors> we should take the name and make that an attributes, plus… Stu has in his proposal an <aboutme> element child with HTML for miscellaneous info. <quote> is also subelement, photo=, location= would be attribute.

>> Any objections?

>> <silence>

>> Jon I'll add that into the spec?

- I had a <help> element in my original proposal; it was to be a URI pointing to documentation for the widget and its properties. We don't seem to have an equivalent tag in the widget metadata. Do we need one?

>> Lori: is there a way in the current spec to facilitate help, a pointer to the documentation for the widget.

>> Stu: content has a URI pointer src attribute in the content mode

>> Lori: the widget itself would have a help mode.

>> Discussion of developer Help use cases, and End User help cases for Mashup assembly.

>> Jon: Lori, when users click help do you open in new window?

>> Lori: Yes

>> Jon: Gadgets have mode for Help within the space of the gadget.

>> Stu: Help mode href="url" of the content to be displayed.

>> Jon: we're all talking the same thing via functionality, disagreeing if it's part of content. If there were a <help> element, it would be equivalent.

>> Stu: Yes, we're circling around the semantics of what content means.

>> Kevin: Could <help> be a subelement of <widget>?

>> Jon: <help> would be a peer to <content> with either src or inline.

>> Stu: No strong objection to moving <help> up as a peer to <content>.

>> Any objection to <help> up as a peer to <content>.

>> Silence

>> Consensus: OK.

- Under <require>, it says "The src attribute holds the relative URL for the given resource, where the base folder is the location of the widget metadata file." Could the src not also be an absolute URL?

>> Jon: I say Yes.

>> Kevin: Objections?

>> Silence

>> Consensus: OK

>> Kevin: OK. That's our hour. Same time next Thursday. Thanks everyone!

Personal tools