[wsrp][markup] Minutes for 5/29/02 conference call

Sub-Committee Lead

Chris Braun

Attending Members:

Sasha Aickin

Jeff Broberg

TJ Cox

Jane Dynin

Gino Filicetti

Michael Freedman

Carsten Leue

Rich Thompson

Thomas Schaeck

1. URL Rewriting - Discussions on 4 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 heuristics to determines URL.

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

Discussion (four scenarios): We still have not come to a consensus on which scenarios should be enforced by the spec. As it stands we are looking at pursuing scenario 2 and/or scenario 4. We should track all stated pros and cons of each approach with examples in the main Markup Document. Most of these pros/cons have been discussed in previous emails. We discussed this topic further.

There were some concerns about scenario 2 being a possible performance issue, as each set of markup has to be parsed so that the proper URL replacements can be made. We can probably get away with requiring such an operation but we should be cognizant of this and look for ways to alleviate the intensity of the process.

There were some concerns that it will be difficult to implement scenario 4. Each platform may have different semantics for what makes up the URL and how it should be encoded (.Net vs. servlet containers). We should get specific examples and add this to the main doc.

It should be possible for the producer to inform the consumer not to rewrite any URLs. This would be desirable if the portlet uses scenario 4.

Static content can not take part in URL rewriting in scenario 4.

Action: Hopefully we will have enough information next week to make a decision on the general semantic to use going forward.

Discussion – (Mechanism and Grammar):

We defined 4 or 5 possible types of URLs that portlets may include as part of their markup:

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

2. Action links – URL rewritten so the consumer can intercept the action and forward the action onto the portlet service via soap.

3. Proxy resource links – 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 URIs the producer sends the consumer the Base URI to be used when generating relative references.

5. Actions to other WSRP services?

One or more tokens may be required but In order to simplify the job for the consumer the token should be parameterized so that a single token can be used. After parsing, the consumer can determine how to do the rewriting based on parameters.

Action: We have not yet touched on grammar. We need to identify which of the 4 rewrite schemes will be supported. We then need to address what tokens will be required for each.

2. CSS Classes – moved to next week’s agenda.

3. Mark-Up Fragment Rules

We previously agreed that it makes sense to allow a portlet writer to append markup to other areas of the containing page besides the body. For example a style or script link may be included in the <head>.

Discussions: There were concerns that each portlet that returned markup outside of the body tag would block the consumer. In order to render the containing page all portlets that need access to the <head> tag would have to complete there markup generation.

It was decided that we would address each tag with the appropriate standards group.

1. xforms:model - XForms and XHTML

2. link – HTML and XHTML

3. script – HTML and XHTML

4. meta - do we need to be concerned with <meta> tags?

5. others?

Most browsers allow such markup to exist in the <body>, however, it does specifically state in the specs that such markup is prohibited. In order to be proactive we should push the appropriate groups to modify the specs to allow for these tags within the confines of a <body> tag as long as the tag occurs before the use.

Consumer defined regions such as tool bar should still be supported by the spec.

Action: Chris Braun will follow up with XFORMS and XHTML/HTML on this for next week.

4. Meeting closed

5. Next Meeting – June 5th

wsrp message