[wsrp-markup] [wsrp][markup] Minutes for 7/10/02 conference call

[Chris Braun <cbraun@silverstream.com>]

Agenda:

 

1. FTF Recap

    a.  Rewrite Scenarios

 

-  At the face to face it was decided that both a Consumer and Producer URL rewrite mechanism are required (scenarios 2 and 4 respectively).  Going forward the terms Producer Rewriting and Consumer Rewriting will be used.

 

    b.  Markup Decomposition

 

- It was decided that an entity can only insert markup within the confines of the portlet's body.  This is in-line with JSR 168.  We will review this requirement in the next release.

 

2. Where to go from here?

    a.  Finalize CSS Classes

 

- Some outstanding CSS issues.  Many classes are undefined and some are redundant.  I will contact the people who proposed the classes with outstanding issues.

 

    b.  Define Rewrite Semantics/Syntax

 

- JSR 168 has the notion of action URLs and render URLs.  An action URL causes an entity to execute its process phase.  By allowing two types of actions the entity can bypass the action phase and allow for the render phase to receive the action parameters.  There is probably nothing that needs to be added to the WSRP protocol to address this.  The producer container will be able to handle this transparently.

 

- The entity should be able to indicate weather an action is blocking or non blocking.  If an action is blocking then the action should be executed before any other entity is rendered.  This discussion will take place in the interfaces subcommittee.  If it is decided that such a mechanism is needed then we will need to add this mechanism to our URL rewrite semantics.

 

- How does the Consumer decide which rewrite type is to be used, Producer or Consumer?  The producer should indicate which approach it wants.

 

- A problem may arise if an entity requires both.  For example an entity pulls content from several sources.  The entity may use Producer URL rewriting in some content and Consumer rewriting for other content.  Possible solutions:

    - 1 The entity sets a flag on the response which indicates weather or not a Consumer rewrite should occur (in addition to the producer's rewrite).  More robust.

    - 2 Require that only one rewrite type can occur per entity.  Simple.

 

Lets pursue 2, the protocol can be modified in the future if the need arises.

 

- It was decided that resource URL is a better term than proxy URL.  

 

- The entity will need a way to indicate when a resource should be cached and when it should be pre-parsed for rewriting by the consumer.  These flags can be contained within the URL as a property. Default behavior should be no cache and no rewriting.

 

- Consumers should rewrite Resource URLs only when explicitly told to do so by the referencing entity.

 

- Rich is going to take a second pass at the URL rewrite semantics.  Hopefully everyone will get a chance to make suggestions via email this week.  The current proposal is in the main markup document.

 

    c.  Markup Rules - cHTML, WML, voiceXML

 

- We should not explicitly discourage the usage of tags.  We will continue to have a list of disallowed tags (tags which if used may break the rendering).  Instead, we should indicate that certain markup specifications may disallow certain tag usage, however most browsers may allow for it.

 

- We haven't discussed possible rules related to cHTMl, WML, and voiceXML.  We will investigate these markups further.  cHTML is an extension of XHTML so it is likely that similar tags will need to be ruled out.

 

    d.  Markup Strawman

 

We need a clearly defined charter and process. 

    - What output is expected of the subcommittee?

    - How is the subcommittees output merged into the specification?

    - Timelines - What needs to be ready for the next FTF?