Re: [wsrp][markup] Minutes for 6/06 conference call

[Chris Braun <cbraun@silverstream.com>]

Second try.

----- Original Message -----

From: Chris Braun

To: WSRP

Sent: Monday, June 10, 2002 6:20 PM

Subject: [wsrp][markup] Minutes for 6/06 conference call

See attached for last weeks minutes.

Title: Leader Chris Braun

Sub-Committee Lead

Chris Braun

 

Attending Members:

Alejandro Abdelnur

Jeff Broberg

Jane Dynin

Gino Filicetti

Michael Freedman

David Taib

Rich Thompson

 

A.     URL Rewriting Scenarios:

 

1. Aggregator sends the prefix with request and portlets must use to do URL boundary demarcation (aggregator does parsing);

 

2. All portlets use pre defined prefix, aggregator parses mark up looking for well known prefix;

 

3. Aggregator automatically parses the mark up uses ………determines URL does rewriting URL (no parsing by aggregator); and,

 

4. Aggregator sends the remote portlet the actual URL to use, aggregator does not require any parsing

 

Discussion:  Scenario’s #2 & #4 can refer to as scenarios of choice.

 

Action:  Review Main Document rev .3, members should provide input, especially URL rewriting, list pros/cons of scenarios.  Especially for scenarios 2 and 4.

 

 

B.     URL Types:

 

1. Fully qualified URL – Nothing needs to be done at the consumer end.

 

2. Action links – Portlet calls action on itself URL rewritten so the consumer can intercept the action and forward the action on to the portlet service via SOAP

 

3. Proxy resource links – Clients accessing resource (thru fire walls).Rewritten so the consumer can intercept the resource request.  The resource can then either be pulled from an internal consumer cache or retrieved via HTTP

 

 

 

4. Relative URI – For relative URI’s the producer sends the consumer the Base URI to be used when generating relative references.

 

5. Actions to other WSRP services. Need qualifications.

 

It is worthwhile to break down the process into four steps.  For each step lets try to identify how the URLs are handled and how these translate on both ends of the equation.

 

Flow using “URL Rewriting Scenario 2”

 

1. Portlet Embeds a token into its markup.
2. Consumer rewrites token as a URI
3. URI is presented to the user as a link, resource reference (i.e. image), or form.
4. User clicks on action link or submits form.
1. Consumer interprets action/link
2. Consumer sends request to portlet

 

Rich will send out an email to get the discussion started on possible approaches to each.

 

Proxy Resource Links: Dynamic content may be proxied.  In this case the content may be session based.  How is the session information passed from consumer to the dynamic resource provider?  Also, may want a way for portlets to indicate that resources should be cached and when a resource has been updated.

 

Actions to Other WSRP:  If you had multiple portlets it would be nice to utilize one.  Example:  contacts – email portlet.  Ability to send email that activated other portlets.  Response sent back to portlet.  Contacts portlet would have exposed an item and request routed to contacts portlet – self activated.  Needs more thought.  We should discuss this further.

 

    

C.    CSS Classes:

1. Tables – removing generic notion not defining own custom class.   Proposal is to combine these two and only have section class instead of table class.

 

Nix ‘Table’ section and move it into ‘Section’ area.

 

2. Section:

 

Assume trail is analogous to paragraph. 

 

 

3. Forms:  label, field, button

 

No modifications.

 

4. Menus: 

 

We added some menu classes such as background.  Need some clarification as to weather cascading menus can be removed assuming that the menu classes can take the cascade menus place.

 

5. Portlet: markup generated by the portlet.

 

We decided that there is no need for general portlet css classes and that section classes can be used to represent a portlet’s content.  Might be worthwhile to identify possible use cases in which a portlet may need its own classes that are different from the section.

 

6. Colors:  It would be nice to allow the portlet to partake in the color theme of the running portal.  For example if a portlet renders a graph then the colors of the graph should be in-line with the other colors on the page.   A graph that has a black bar would not want to reside in a table with a black background.

 

This is a valid problem however CSS may not be powerful enough to solve it.  Let’s come up with a list of use cases and a possible prototype where CSS might be able to help solve this issue.  If this does not seem viable we can try to address this in a later spec version.

 

      7.   Other

 

·        Position

·        Media Properties

·        Background properties

·        Margins

·        Spacing

 

General consensus was that these areas can be addressed by using the other classes.  Would like more information on these before we remove them to make sure this is the case.

 

 

Attachment: Minutes-June-5.doc
Description: MS-Word document