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

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:

 

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

 

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

 

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

 

 
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:

 

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

 

 
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

 

 
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

 

 

 

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

 

 
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”

 

 
Portlet Embeds a token
     into its markup.

 
Consumer rewrites token as
     a URI

 
URI is presented to the
     user as a link, resource reference (i.e. image), or form.

 
User clicks on action link
     or submits form.

 
  
Consumer interprets
      action/link

  
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:

 
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.

 

 
Section: 

 

Assume
trail is analogous to paragraph.  

 

 

 
Forms:  label, field, button

 

No
modifications.

 

 
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.

 

 
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.

 

 
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