Revision History

Date	Version	Description	Author
4/16/2002	0.0	Initial Draft	David Taieb
4/17/2002	0.1	Initial Changes	Gino Filicetti
5/9/2002	0.2	Changes based on 5/8/2002 concall	David Taieb
6/5/2002	0.3	Rewriting scenarios	David Taieb

Table of Contents

1. Goals of this document 1

2. Visual Themes 1

2.1 Problem Description 1

2.2 CSS classes: 1

3. Markup Fragment Rules 2

3.1 Problem description 2

3.2 HTML 2

3.2.1 HTML validation rules 2

Disallowed 2

Discouraged 2

3.3 XHTML Basic 2

3.3.1 XHTML Basic Validation rules 2

Disallowed 2

Discouraged 2

3.4 Other Markups 3

3.5 Markup Fragment decomposition 3

4. Secure resources: 3

4.1 Problem Description 3

4.2 Proxy 3

4.3 Caching the resource 3

5. URL Rewriting 3

5.1 Problem Description 3

5.2 Rewriting scenarios 3

5.2.1 Using a prefix sent by the aggregator 3

5.2.2 Using a predefined prefix 3

5.2.3 At the aggregator side 4

5.2.4 At the producer side (with URL prefix sent by the aggregator) 4

5.2.5 Discussion about the 4 URL rewriting scenarios: 4

5.3 Mechanism used to demarcate URLs 4

6. Namespacing/Prefixing 5

6.1 Problem Description 5

6.2 Named attributes 5

6.3 JavaScript methods and variables 5

6.3.1 Prefixing: 5

Is there any reason to treat them any differently from Named attributes? 5

6.3.2 Cross portlet JavaScript methods and variables: 5

WSRP Markup/Style Document

1. Goals of this document

To define standard mechanisms to allow common look and feel across aggregated portlets

To specify the rules that define valid markup fragments for all the markup languages allowed. These include by order of priority: HTML, XHTML, Other (WML, cHTML, VoiceXML, …)

To define standard mechanisms for URL rewriting and namespace encoding. These problems are also of interest to the interface subcommittee and therefore the two efforts will stay in sync.

2. Visual Themes

2.1 Problem Description

As WSRP services are consumed, we need a mechanism to provide a consistent look and feel across all the aggregated portlets.

2.2 CSS classes:

Since WSRP classes are a subset of the WSIA classes, WSRP will eventually use a WSIA namespace using “wsia-“ as a prefix

CSS classes submitted by WSUI and IBM WPS:

	WSUI	IBM WPS
Links		A A:visited A:hover
Fonts	wsui-font wsui-font-small wsui-font-large wsui-dim wsui-dim-small wsui-error wsui-error-small wsui-ok wsui-ok-small wusi-form-label	.portletText .portletSmText .portletTinyText .buttonText .fieldErrorText
Tables	wsui-table wsui-table-row-header wsui-table-row-sectionheader wsui-table-row-odd wsui-table-row-even	.tableHead .tableText .tableShdRow
Sections	wsui-section-title wsui-trail wsui-trail-current	.portletTitle .portletTitleCust
General	wsui-page-title wsui-block-bgcolor	UL .portletColorBack .portletHead .portletBody .portletBack
Menus	wsui-menu wsui-menu-current

3. Markup Fragment Rules

Because markup fragments, produced by each remote portlet, are aggregated by the consumer portal into a single page, some rules and limitations are needed to make sure of the coherence of the resulting page to be displayed to the end user.

The markup validation rules might also depend on the type of aggregation environment used to embed the output of the portlets: Tables vs. framesets (or may be a combination of both?) (If we allow multiple choices, is this a property that’s needed to be propagated to the producer?).

By order of priority, we’ll define validation rules to the following markup languages :

-HTML: most commonly used markup language

-XHTML Basic: becoming a standard for cellular phones. We should also consider impacts of XHTML derived markups like XHTML Mobile profile, etc…

-cHTML, WML, VoiceXML, etc…

Another problem is that markup fragments are eventually embedded into markup tag containers (like table cells for instances), this greatly reduce the possibility for the remote portlet to expose tags (or other items like JavaScript methods/variables) that must appears in a global scope. One possible solution is for the aggregator to request separately any global markup that must occurs outside the content of the portlet and the portlet content itself.

3.2 HTML

Because disallowed tags might potentially have an impact on other portlets or even break the whole aggregated page, its inclusion will invalidate the whole markup fragment which will be replaced by an error message.

3.2.1 HTML validation rules

Disallowed	Discouraged
base	link
body	meta
frame	style
frameset
head
html
title

3.3 XHTML Basic

3.3.1 XHTML Basic Validation rules

Disallowed	Discouraged
base	link
body	meta
Head
html
title

3.4 Other Markups

…

3.5 Markup Fragment decomposition

Proposition to decompose the markup output into 3 sections like header, body and footer: we should have an extensible set of sections names, WSRP will define a standard base set that will be extensible (in future releases of WSRP and privately by the consumer) and it would be up to the consumer whether to support them or not. This group is opened to any suggestion as to what this base set should be composed of.
This standard base set should depend on the content type (some section might make sense for a markup language but not for others).

4. Secure resources:

4.1 Problem Description

The client might not always have direct access to resources (like java applets, images, etc…) embedded in the portlet because of network topology reason for instance.. Therefore, after the link URI is being rewritten to point to the aggregator, the aggregator must provide a transparent mechanism that ensures availability of the resource by acting as a proxy between the user and portlet. The aggregator might also decide to proxy a cached version of the resource.

Question: How does the portlet indicates that a resource needs to be proxied (especially for these URL that are dynamically generated using JavaScript).

4.2 Proxy

The aggregator proxies the request from the client to the remote portlet and proxies back the resource to the client.

Note: we need to make sure that security, privacy and access control are not compromised during the proxying process.

4.3 Caching the resource

The aggregator caches the resource from the remote portlet and directly serves it to the client.

Question: what standard do we apply for determining that a resource has expired?

5. URL Rewriting

5.1 Problem Description

URLs embedded in markup fragment cannot be direct links to the original producer but must be encoded so that they are intercepted by the aggregator and re-routed back to original producer. Because the same portlet can be instantiated more than once in a same page, encoded URL will have to allow aggregator to track the portlet instance to which the request is intended for.

The producer and the Consumer will work together to maximize efficiency of URL encoding and routing of requests.

5.2 Rewriting scenarios

5.2.1 Using a prefix sent by the aggregator

The Aggregator sends a prefix with the request that the producer will use to do the URL boundary demarcation. The aggregator then parses the markup looking for the prefix it provided.

5.2.2 Using a predefined prefix

All portlets use a predefined prefix, which is part of the specification, to do the URL boundary demarcation. The aggregator then parses the markup looking for the well known prefix.

5.2.3 At the aggregator side

The aggregator automatically parses markup and heuristically determines URL boundaries and does the necessary rewriting automatically.

5.2.4 At the producer side (with URL prefix sent by the aggregator)

The aggregator sends the URL prefix to use to the remote portlet, allowing it to do the rewriting itself on all the necessary URL. The markup sent back to the aggregator is then ready for immediate inclusion in the page, with no parsing necessary.

Note : We could consider a variation of this scenario where the remote portlet can choose not to rewrite all the URLs and will use the same algorithm as in 5.2.2 to demarcate the URL. It is then up to the aggregator to identify and rewrite all the remaining URLs using the prefix used by the producer.

5.2.5 Discussion about the 4 URL rewriting scenarios:

Scenario	Pros	Cons	Recommendation
5.2.1	Text based parsing at the aggregator side easy to implement and very efficiation.	Parsing at the aggregator side as well as prefix inclusion at the producer side can cause a performance problem.
5.2.2	Text based parsing at the aggregator side easy to implement and very efficiation. Because the prefix is known in advance, the producer needn’t do any processing at run time.	Parsing at the aggregator side. Uniqueness problem for JavaScript functions and variables when two instances of the same portlet coexist in the same page.
5.2.3	If it works, it would require no work from the producer making the system very generic and truly plug and play	Extremely complicated to implement The URL rewriting algorithm would have to be markup agnostic Error prone	Poor
5.2.4	No rewriting at the aggregator side	As we can’t assume what makes up a URL, and how it should be encoded (.NET vs. J2EE), implementation can be difficult. Static content cannot take part in URL rewriting

5.3 Mechanism used to demarcate URLs

The producer uses an escape sequence that contains all the parts of the URLs followed optionally by some parameters. The aggregator then searches this sequence and reconstructs the URL using the correct URL prefix.

Advantages: this method is parsing efficient and should be easy to implement.

TODO: more details about the algorithm

6. Namespacing/Prefixing

6.1 Problem Description

Aggregating multiple portlet from different sources can potentially result in naming conflicts for various types of elements: named attributes, JavaScript functions and variables, etc…

6.2 Named attributes

Named attributes identify (uniquely or not) items in the markup fragment. For examples, named attributes in HTML are represented using the “name” or “id” attribute and more often than not are referenced by the application and therefore should be encoded to ensure portlet integrity. The uniqueness of the encoded attribute will have to also be preserved for each instance of the same remote portlet running on the page.

As the only criteria for encoding the named attribute is uniqueness (as oppose to URL rewriting where the encoded URL must be redirected to the aggregator itself), do we need information from the consumer?

wsrp message