Multiple content section ambiguity.

[Kevin Brown]

While implementing multiple content sections in Shindig, Paul Lindner and myself discovered some ambiguity in the spec.

Today the spec says the following about multiple content sections:

"Multiple Content sections may be specified in gadget XML. Each is labeled with one or more view identifiers, which allow the gadget to behave or appear differently depending on the context in which it's rendered. This context is provided by the gadget container."

There are 4 undefined cases:

1. How is the "view" identifier specified, and what is the format?
2. What if the same view is specified more than once?
3. What if there is no view specified matching what the container wants to render?
4. What if there is no "view" attribute present at all?

Our proposed solution:

#1 -- Comma separated list in the view attribute of the Content section (in practice, this is exactly what all known containers that already support multiple views have implemented, so there shouldn't be any contention here).

#2 -- Concatenate all views with a matching name together, in declared order. Shindig (Orkut and hi5 are deployed on this) implement this today, and we think it's a useful way to allow for code reuse.

#3 -- We believe that we should look for a view named "default" in this case. Shindig (Orkut + hi5) implements this now.

#4 -- We believe that the lack of a view attribute should be assumed to be equal to "default" (when combined with #3, this ensures maximum compatibility).

Additionally, we realize that there will be cases where gadget authors will have to specify a large number of views in complicated gadgets for the concatenation process when they support a large variety of view values. To remedy this, we propose one special value for view: asterisk (*).

Some examples of what we believe to be a "correct" conforming implementation.

<Content type="html" view="*">View A</Content>
<Content type="html" view="canvas">View B</Content>
<Content type="html" view="default">View C</Content>
<Content type="html" view="canvas, profile">View D</Content>
<Content type="html" view="profile">View E</Content>
<Content type="html">View F</Content>

For view = canvas:
View A View B View D

For view = profile:
View A View D View E

For all other views (assumed to be "default"):
View A View C View F

Since this is the way that Shindig has this implemented today, and both Orkut and hi5 have releases pending in the near future that depend on this behavior being define, we would like to reach a decision by the end of the week so that we can effectively notify gadget authors before we go live.

Thanks,

~Kevin

[Evan Gilbert]

I'd rather use the first matching view than use concatenation.

Concatenating for building HTML pages works poorly for all but the most simple cases.

Evan

[Kevin Brown]

On Thu, Feb 28, 2008 at 3:58 PM, Evan Gilbert <uid...@google.com> wrote:

I'd rather use the first matching view than use concatenation.

Concatenating for building HTML pages works poorly for all but the most simple cases.

It's only the "most simple cases" that we're trying to deal with. If you have common code in the main section of your gadget, but different header / footer content depending on the view, this definition would allow you to avoid lots of error-prone code duplication.

Consider:

<Content type="html" view="canvas">lots of css and javascript</Content>
<Content type="html" view="profile">different (but still lots) of css and javascript that behaves in a different way compared to canvas</Content>
<Content type="html" view="canvas, profile">body content</Content>

--
~Kevin

If you received this email by mistake, please delete it, cancel your mail account, destroy your hard drive, silence any witnesses, and burn down the building that you're in.

[Evan Gilbert]

I agree this is a useful

On Thu, Feb 28, 2008 at 4:09 PM, Kevin Brown <et...@google.com> wrote:

On Thu, Feb 28, 2008 at 3:58 PM, Evan Gilbert <uid...@google.com> wrote:

I'd rather use the first matching view than use concatenation.

Concatenating for building HTML pages works poorly for all but the most simple cases.

It's only the "most simple cases" that we're trying to deal with. If you have common code in the main section of your gadget, but different header / footer content depending on the view, this definition would allow you to avoid lots of error-prone code duplication.

Consider:

<Content type="html" view="canvas">lots of css and javascript</Content>
<Content type="html" view="profile">different (but still lots) of css and javascript that behaves in a different way compared to canvas</Content>
<Content type="html" view="canvas, profile">body content</Content>

I agree this is a useful example. However I'm worried that we that we'll end up with multiple conflicting ways to implement shared content because this is a solution that only works for a few use cases out of the many for sharing content.

Other possible ways of sharing in the interim:
1. Include the same JS file (these could document.write() CSS as well)
2. Have a require feature for JS/CSS with parameters for what <Content> types it gets injected into

This also doesn't work well if we ever allow different content types (url, xml, etc) - think it makes sense to think of a single <Content> block as the definition for a section.

Evan

[Bruno Bowden]

The other part that needs to be specified is the precedence order for the attributes. For example, should the following gadget be rendered in quirks mode or not?

  <Content type="html" quirks="true">...</Content>
  <Content type="html" quirks="false">...</Content>

Following the style of CSS, the last mention of the attribute should take precedence. So for the preceding gadget, it would be rendered with quirks="false".

Reject gadgets:
- with multiple views for type=url
- when type=url and type=html defined for the same view



One unfortunate consequence is because of the way that I expect people to design gadgets, they'll separate the CSS using this system. Consider the case of altering the CSS slightly for one of the views. In this case, the the "profile" view just modifies a small part of the CSS:

<Content type="html" view="*">

    ALL_CSS
    ALL_HTML

</Content>
<Content type="html" view="profile">

    PROFILE_CSS
</Content>

This slows down rendering in IE as the CSS is split across the HTML. I doubt developers would do it but rendering would be faster with:

<Content type="html" view="*">

    ALL_CSS

</Content>
<Content type="html" view="profile">

    PROFILE_CSS
</Content>
<Content type="html" view="*">
    ALL_HTML
</Content>

Caja can do this type of analysis and combine the CSS across multiple Content sections (and indeed multiple gadgets), to put it together at the start of the page.

Other possible ways of sharing in the interim:
1. Include the same JS file (these could document.write() CSS as well)

This is already possible and doesn't need any special support. It is not best practice as it introduces latency and makes cajoling more difficult.
 

2. Have a require feature for JS/CSS with parameters for what <Content> types it gets injected into

Multiple Views should be orthogonal to the Requires tags. Though it's conceivable that a feature may not be needed for a particular view, it adds too much complexity.
 

[Kevin Brown]

Does anyone else have any feedback on this issue? Several launches are pending, and resolving this sooner rather than later would be ideal. Here is my proposed modification to the spec:

Remove this paragraph: "Multiple Content sections may be specified in gadget XML. Each is labeled with one or more view identifiers, which allow the gadget to behave or appear differently depending on the context in which it's rendered. This context is provided by the gadget container."

Add the following section between "Process" items 2 and 3, or possibly as a sub-section of item 2:

============================

Process <Content> elements as defined in the canonical xsd, applying the following rules to the optional "view" attribute:

1. Process "view" as a comma-separated list of names. Whitespace between names MUST be ignored. Referred to hereafter as view names.
    a. If no "view" attribute is present, the assumed value MUST be "default".

2. Select the view name that most closely matches the view that you are currently displaying to your end user. If more than one view uses the same name:
   a. If any "type" attribute is "url", the specification is malformed, the server SHOULD display an error message.
   b. If all "type" attributes are "html", the CDATA of the matching elements MUST be concatenated together in the same order as declared.
   c. Any attributes on the element other than "view" and "href" MUST cascade through other elements, with the last declared value being the value used for all future work.
   d. If none of the declared view names match the requested view, the server MUST first look for a view named "default" and repeat this process. If no match is found for "default", the server SHOULD display an error message.

=============================

Getting resolution on this is very important to orkut and hi5, and I'm sure to other containers as well. If any containers have objections, please speak up now.

[Bruno Bowden]

In regards to this:

   c. Any attributes on the element other than "view" and "href" MUST cascade through other elements, with the last declared value being the value used for all future work.

I was unclear on the meaning of "all future work"? Another important point is that  the attribute applies across the whole concatenated gadget, not just individual sections, e.g. you can't mix and match Content sections with quirks on and off.

   c. Any attributes on the element other than "view" and "href" MUST cascade through other elements, with the last declared value applying to the complete concatenated contents.

[Kevin Brown]

That sounds more concise, yes.

--
~Kevin

[Evan Gilbert]

Does the concatenation enhancement help for more than sharing JS and CSS includes?

If this is the only use case we're addressing, I still have a preference for finding a more limited solution for JS/CSS sharing. If we're looking at ways to combine content sections together, we should compare this approach with other options - for example we could have a substitution variable that refers to the entire contents of another content section.

Evan

On Tue, Mar 4, 2008 at 2:01 AM, Kevin Brown <et...@google.com> wrote:

[Kevin Brown]

I think we should put this discussion to some of the larger gadget developers out there who have been looking for solutions along these lines. There are > 100 people subscribed to this list, so if you are a developer we would appreciate your help in determining the best course of action here.

--
~Kevin

[Henry Stapp]

Hi All,

I think the problem here is that we're trying to shoehorn the idea of
Content and the idea of a View into the same element - these are
actually separate concepts and should probably be different elements.

One thing, for example, that we haven't discussed yet, is how varying
views need to have different heights and widths. In the current spec,
height and width are part of ModulePrefs. This is a hold-over the
original iGoogle way of doing things, where a module had only one view
and one content section. A better way would be to have a View element,
that specified the height and width, as well as the content that
should be rendered in that view.

Here's a new suggested structure:

<Content id="mainContent">...</Content>
<View name="profile" alignment="left" height="500" width="30">
<ContentArea contentId="mainContent"/>
</View>

- The Content element has the following attribute added:
-"id". Optional. A string which uniquely names that content.

- A new optional "View" element is added. It has the following
attributes:
- "name". Required. ("profile"|"home"|"canvas"). The view surface
on which to display the content.
- "alignment". Optional. ("left"|"middle"|"right"). Indicates to
the container the preferred column to render the gadget on (if
applicable).
- "height" and "width". Optional. Int. Indicates to the container
the preferred height and width to render the gadget with.

- The View element can contain one or more ContentArea elements.

- The ContentArea element contains one attribute:
- "contentId". Required. A string that matches the id attribute
from of the defined "Content" elements, and indicates which content to
display in the View.

This would be backward compatible. So an iGoogle-style gadget (with
height and width in ModulePrefs, one Content area with no id or view
attributes, and no View elements) would render in the default view
(probably "home" for MySpace) with the height specified in
ModulePrefs.

What do you think?

Thanks,

Henry Stapp

hstapp at myspace

On Mar 4, 10:20 pm, "Kevin Brown" <e...@google.com> wrote:
> I think we should put this discussion to some of the larger gadget
> developers out there who have been looking for solutions along these lines.
> There are > 100 people subscribed to this list, so if you are a developer we
> would appreciate your help in determining the best course of action here.
>
>
>
>
>
> On Tue, Mar 4, 2008 at 8:26 PM, Evan Gilbert <uid...@google.com> wrote:
> > Does the concatenation enhancement help for more than sharing JS and CSS
> > includes?
>
> > If this is the only use case we're addressing, I still have a preference
> > for finding a more limited solution for JS/CSS sharing. If we're looking at
> > ways to combine content sections together, we should compare this approach
> > with other options - for example we could have a substitution variable that
> > refers to the entire contents of another content section.
>
> > Evan
>

> > On Tue, Mar 4, 2008 at 2:01 AM, Kevin Brown <e...@google.com> wrote:
>
> > > Does anyone else have any feedback on this issue? Several launches are
> > > pending, and resolving this sooner rather than later would be ideal. Here is
> > > my proposed modification to the spec:
>
> > > Remove this paragraph: "Multiple Content sections may be specified in

> > > gadget XML. Each is labeled with one or more *view* identifiers, which

> > > allow the gadget to behave or appear differently depending on the context in
> > > which it's rendered. This context is provided by the gadget container."
>
> > > Add the following section between "Process" items 2 and 3, or possibly
> > > as a sub-section of item 2:
>
> > > ============================
>
> > > Process <Content> elements as defined in the canonical xsd, applying the
> > > following rules to the optional "view" attribute:
>
> > > 1. Process "view" as a comma-separated list of names. Whitespace between

> > > names MUST be ignored. Referred to hereafter as *view names.
> > >     *a. If no "view" attribute is present, the assumed value MUST be

> > > "default".
>
> > > 2. Select the view name that most closely matches the view that you are
> > > currently displaying to your end user. If more than one view uses the same
> > > name:
> > >    a. If any "type" attribute is "url", the specification is malformed,
> > > the server SHOULD display an error message.
> > >    b. If all "type" attributes are "html", the CDATA of the matching
> > > elements MUST be concatenated together in the same order as declared.
> > >    c. Any attributes on the element other than "view" and "href" MUST
> > > cascade through other elements, with the last declared value being the value
> > > used for all future work.
> > >    d. If none of the declared view names match the requested view, the
> > > server MUST first look for a view named "default" and repeat this process.
> > > If no match is found for "default", the server SHOULD display an error
> > > message.
>
> > > =============================
>
> > > Getting resolution on this is very important to orkut and hi5, and I'm
> > > sure to other containers as well. If any containers have objections, please
> > > speak up now.
>
> --

> ~Kevin- Hide quoted text -
>
> - Show quoted text -

[Kevin Brown]

I think adding those pref annotations to the content section solves the problem anyway, without introducing entire new elements and a forked processing tree: <Content view="profile" height="300" width="500">. If we're confining the scope to only solve that sort of problem, I think a significant change to the spec is unnecessary.

However, a new element would definitely be preferable for resolving other issues, such as certain features only being required on one view or another, as in:

<View name="canvas">
  <Require feature="opensocial-0.7"/>
  <Content type="html"><![CDATA[...complex stuff that should only be on the canvas page...]]></Content>
</View>
<View name="profile">
  <Content type="html">Hello, profile!</Content>
</View>
<View name="home">
  ...

I think a radical change such as that, though, would necessitate a different, versioned schema. We could then trivially identify which schema was in use based on either a doctype or a namespace declaration on the <Module> element. I think something like this is going to be necessary anyway in order to facilitate evolving the spec in meaningful ways.

--
~Kevin

[Henry Stapp]

Yeah. +1 on the versioned schema. We're jumping through hoops trying
to work within some of the assumptions of the iGoogle schema which no
longer apply.

> - Show quoted text -- Hide quoted text -

[Cassie]

Okay, so for the next version of the spec do we want to
1. go with a simple but slightly awkward concatenation model or
2. should we version the gadget xml and introduce new elements to better accomodate the concept of views?


If we want to do #1 would we rather
1a. concatenate all sections with the correct view name as described by the proposal below, or
1b. only accept the first content section with the correct view name. not allowing any concatenation.


So far the opinions have been as follows:
1a - Kevin, Bruno
1b - Evan
2 - Henry (and possibly Kevin)


It does not appear that there has been enough consensus to go forward with any changes to the spec. So.. please chime in with your opinion/vote!
Let me know if I misstated anything. Thanks.


- Cassie


----------------------------------------------------------------------------------------
Concatenate all sections spec change:


Remove this paragraph: "Multiple Content sections may be specified in gadget XML. Each is labeled with one or more view identifiers, which allow the gadget to behave or appear differently depending on the context in which it's rendered. This context is provided by the gadget container."

Add the following section between "Process" items 2 and 3, or possibly as a sub-section of item 2:

============================

Process <Content> elements as defined in the canonical xsd, applying the following rules to the optional "view" attribute:

1. Process "view" as a comma-separated list of names. Whitespace between names MUST be ignored. Referred to hereafter as view names.
    a. If no "view" attribute is present, the assumed value MUST be "default".

2. Select the view name that most closely matches the view that you are currently displaying to your end user. If more than one view uses the same name:
   a. If any "type" attribute is "url", the specification is malformed, the server SHOULD display an error message.
   b. If all "type" attributes are "html", the CDATA of the matching elements MUST be concatenated together in the same order as declared.

   c. Any attributes on the element other than "view" and "href" MUST cascade through other elements, with the last declared value applying to the complete concatenated contents.

   d. If none of the declared view names match the requested view, the server MUST first look for a view named "default" and repeat this process. If no match is found for "default", the server SHOULD display an error message.

=============================

[Evan Gilbert]

On Tue, Apr 1, 2008 at 5:27 AM, Cassie <do...@google.com> wrote:

Okay, so for the next version of the spec do we want to
1. go with a simple but slightly awkward concatenation model or
2. should we version the gadget xml and introduce new elements to better accomodate the concept of views?


If we want to do #1 would we rather
1a. concatenate all sections with the correct view name as described by the proposal below, or
1b. only accept the first content section with the correct view name. not allowing any concatenation.

As the only +1 on this option so far, I will point out that it is not a "simple but slightly awkward concatenation model", as it doesn't concatenate. "First content section wins!" is probably a good summary.
 

[Reinoud Elhorst]

+1 on Henry's proposal ( so I guess that's 2), it seems the cleanest way to do things.

[Paul Walker]

I think we can close this thread out in lieu of Brian and Henry’s recent proposals. 

[Cassie]

Paul is referring to this thread here:
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/1845cdb2f3d17777

The issues have been merged in the spreadsheet.

- Cassie