Gadgets Minutes 2008-6-11

From MemberWiki

Jump to: navigation, search
  • Stewart Nickolas <nickolas(at)>
  • Rama Gurram <rama.gurram(at)>
  • Howard Weingram
  • Jon Ferraiolo <jferrai(at)>


Stew: We'll use the agenda located here for the discussion today: /member/wiki/Gadget_Content_Types

Stew: The current IDE Widget Metadata specification does NOT explicitly include the 'url' type from the gadget proposal. This is an important type for mapping to google gadgets as well it enables developers to quickly offer up existing fragments of content.

Stew: The proposal is to use the 'src' property on the content element which points to the site containing the content to be used. When the src is set the content should be untrusted as a general rule. Jon: Its better not to have implicit semantics associated with the src attribute.

Stew: OK, let discuss the use of a type attribute plus a src attribute

Stew: From the Gadgets proposal the type attribute is interpreted as follows:

     type - OPTIONAL string specifying how to treat the content contained in the section. Type supported include:
     html - content is to be spliced inline with the page or assembly canvas
     url - the href points to the content of the widget, in which case an IFRAME is spliced into the assembly canvas pointing to the widget. NOTE: For url content, the <resource> tags are ignored since the Gadget's content rendering is completely delegated to the URL within its own IFRAME.
     frame - the content of the section is contained within a IFRAME for security and other runtime related requirements, this is the default

Jon: What is frame?

Stew: That maps to sandbox in the IDE WG spec

Stew: So the triple: mode, type, href specified the exact content and semantics.

Jon: So, mapping to the IDE Widget spec, href is the same as src?

Stew: yes, additionally 'src' only makes sense when type="url"

Stew: We'll need to add the type attribute as well to the IDE Widget spec.

Jon: OK, so what happens to the type attribute in the IDE WG spec (e.g. view|edit|help)?

Stew: We can use the name 'view' instead of type as defined in the Gadgets proposal

Jon: OK, I don't like view='view' though, we need a better name.

Stew: Yes

Rama: how about 'default'

Jon, Stew: OK

Jon: So we have view='default|edit|help'

Stew: yes

Stew: OK, lets move on to the mapping to Google Gadget view

Stew: From the google spec: "...A view is a location in a container where a gadget is displayed. Different views have different characteristics. For example, a container might have a view that shows gadgets in a small format, and a view that shows gadgets in full page format..."

Stew:The Google Gadgets (update specification) 'view' attribute maps semantically to the Gadgets Taskforce attribute 'mode' whose values could be 'view|edit|help'.

Stew: The IDE Widget Metadata currently does not support 'view concatenation', for example view='canvas, home' allows an assembly convas to use either canvase OR home.

Jon: We should support that

Stew,Rama: agreed

Stew: Should we use QNAME for views?

Jon: Yep

Jon: I'll make the changes to the IDE Widget metadata we spoke of

Personal tools