Revision History

Date	Version	Description	Author
4/16/2002	1.0	Initial Draft	David Taieb
4/17/2002	1.1	Initial Changes	Gino Filicetti

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 1

3.1 Problem description 1

3.2 HTML 2

3.2.1 HTML validation rules 2

Tags 2

Comment 2

3.3 XHTML Basic 2

3.3.1 XHTML Basic Validation rules 2

3.4 Other Markups 2

4. URL Rewriting 3

4.1.1 Problem Description 3

4.1.2 At the Producer side 3

4.1.3 At the aggregator side 3

5. Namespacing/Prefixing 3

5.1 Problem Description 3

5.2 Named attributes 3

5.3 JavaScript methods and variables 3

5.3.1 Prefixing: 3

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

5.3.2 Cross portlet Javascript methods and variables: 3

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:

CSS classes submitted by WSUI :

	WSUI
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
Tables	wsui-table wsui-table-row-header wsui-table-row-sectionheader wsui-table-row-odd wsui-table-row-even
Sections	wsui-section-title wsui-trail wsui-trail-current
General	wsui-page-title wsui-block-bgcolor
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

3.2.1 HTML validation rules

List of disallowed tags:

Tags	Comment
base
frame
frameset
head
html
link
meta
style

3.3 XHTML Basic

3.3.1 XHTML Basic Validation rules

List of disallowed tags:

XHTML Module	tag	Comment
Structure Module	body	the body itself
	head	outside of the body
	html	outside of the body
	title	outside of the body
Metainformation Module	meta	only in the HEAD section
Link Module	link	only in the HEAD section
Base Module	base	only in the HEAD section

3.4 Other Markups

�

4. URL Rewriting

4.1.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.

4.1.2 At the Producer side

Each URL that needs to be encoded is prefixed with a unique token used as a placeholder for encoding the URL. This token will depend on the WSRP service itself but also on the instance of the portlet the markup is generated for. <<TODO : define the information needed from the consumer to create this token >>

4.1.3 At the aggregator side

Knowing the prefix token, the aggregator will do a simple text search (no document object model tree needs to be created) and replace the token with the correct links.

5. Namespacing/Prefixing

5.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�

5.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

�