OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [wsrp][markup]Markup document (updated revision)

Hi All,
      Here are the latest version of the Markup master document based on
the latest concall
(See attached file: WSRP Markup.doc)(See attached file: WSRP Markup.htm)
David Taieb
Advisory Software Engineer
Lotus Software, IBM Software group
One Rogers Street
Cambridge, MA 02142
Tel : (617) 693 5819
Fax : (617) 693 5542

Attachment: WSRP Markup.doc
Description: MS-Word document

Title: WSRP Markup, Style and Rewriting Specifications

WSRP Markup, Style and Rewriting Specifications

Version 1.2





Revision History







Initial Draft

David Taieb



Initial Changes

Gino Filicetti



Changes based on 5/8/2002 concall

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    At the Producer side                                                                                                                                         3

5.2.2    At the aggregator side                                                                                                                                      3

5.3      Mechanism used to demarcate URLs                                                                                                                       4

6.     Namespacing/Prefixing                                                                                                                                                            4

6.1      Problem Description                                                                                                                                                    4

6.2      Named attributes                                                                                                                                                         4

6.3      JavaScript methods and variables                                                                                                                            4

6.3.1    Prefixing:                                                                                                                                                              4

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

6.3.2    Cross portlet JavaScript methods and variables:                                                                                          4

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:
























































3.     Markup Fragment Rules

3.1     Problem description

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



















3.3     XHTML Basic

3.3.1     XHTML Basic Validation rules















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     At the Producer side

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. If no prefix is provided, the portlet will use a standard one defined in this spec.

5.2.2     At the aggregator side

The aggregator sends the URL prefix to use to the remote portlet, allowing it to do the rewriting itself on all the necessary URL. However, the remote portlet can choose not to rewrite all the URLs and will use the same algorithm as in 5.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.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?

6.3     JavaScript methods and variables

6.3.1     Prefixing:

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

6.3.2     Cross portlet JavaScript methods and variables:

To provide a mechanism to expose to all aggregated portlets, JavaScript methods / variables declared from a particular portlet.

Examples of global JavaScript method/variable use : data query between portlets, data writing between portlets, etc…






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC