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: Re: [wsrp][markup] Second conference call

Here's a draft document that outlines the differents issues raised at our
first conference call and tries to capture the email discussions that

(See attached file: WSRP Markup.html)(See attached file: WSRP Markup.DOC)

|         |           Gino Filicetti   |
|         |           <gfilicetti@bowst|
|         |           reet.com>        |
|         |                            |
|         |           04/18/2002 06:33 |
|         |           PM               |
|         |                            |
  |                                                                                                                              |
  |       To:       "'wsrp@lists.oasis-open.org'" <wsrp@lists.oasis-open.org>                                                    |
  |       cc:       (bcc: David Taieb/Cambridge/IBM)                                                                             |
  |       Subject:  [wsrp][markup] Second conference call                                                                        |


The time has come for our 2nd conference call.... I didn't bother
it this week because of the clash with the WSIA F2F... Here is the

Date: Tuesday, April 23, 2002
Time: 12:00 PM Eastern, 9:00 AM Pacific
Duration: 1 Hour

 To join this conference:

For quick access, go to https://bowstreet.spiderphone.com/27914907
(This link will help connect both your browser and telephone to the call)

OR dial 1 (866) 633-2978 or +1 (646) 485-9300 and enter 2791 4907


Here is a list of issues that we've been grappling with over email since
last conference call; I'd like to discuss each one, and see where that
us. It's a pretty long and exhaustive list and it's fully expected that we
may not be able to hit each one during this call.....

- Should we standardize on XHTML? Do we want to discourage the use of old
style HTML but still accept it? Or refuse non-parsable HTML out-right?

- Acceptable tags in (X)HTML
  - should we specify a list of ALLOWED or DISALLOWED tags?
  - are there some tags that aren't exactly DISALLOWED but rather
  - go over the currently proposed list of disallowed tags in (X)HTML
    - base, body, frame, frameset, head, html, link, meta, style, title

- Should a portlet be aware of its surroundings?
  - does the portal have to tell the portlet what it's surrounding tag will

- Do we want to tackle VoiceML and WML now?

- How do we deal with signed java applets, images and other resources that
the aggregator is going to have to proxy?

- Carsten proposed that portlets could send their markup in 3 sections,
begin page, main markup fragment and end page. This would allow a portlet
insert markup into other places in the final page that the aggregator
  - Sasha believes we should either make the possible locations that a
portlet can insert markup into extensible (ie: not hardwired to 3), or just
restrict it to one location.

- how will portlets define and use javascript methods?
- how will we encode javascript elements?
- will there be shared methods?

URL Rewriting
- Three suggestions on the table (first 2 from Carsten, third from Sasha)

1. Aggregator sends a prefix w/ request and portlet must use it to do the
URL boundary demarcation. The aggregator then parses the markup looking for
the prefix it provided.

2. All portlets use a predefined prefix which is part of the spec to
demarcate URL boundaries. The aggregator then parses the markup looking for
the well known prefix.

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

- Is a prefix good enough to demarcate a URL? Do we need a more robust
  - Sasha suggests taking advantage of XML namespaces, and using regular
tags to demarcate a URL.

Namespace Encoding
- the mechanism used to encode namespaces should be the same the used in
- what types of things need to be encoded?
  - form and input names
  - javascript variables
- How does this impact the portlet writer and their pre-existing

Visual Styles
- only very preliminary discussion has been done.
- lists of possible styles have been submitted by Thomas (used in WSP) and
Alan (used in WSUI): see attached file.

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

Title: WSRP Markup, Style and Rewriting Specifications

WSRP Markup, Style and Rewriting Specifications

Version 1.1





Revision History







Initial Draft

David Taieb



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 :


































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

3.2.1     HTML validation rules

List of disallowed tags:




















3.3     XHTML Basic

3.3.1     XHTML Basic Validation rules

List of disallowed tags:

XHTML Module



Structure Module


the body itself



outside of the body



outside of the body



outside of the body

Metainformation Module


only in the HEAD section

Link Module


only in the HEAD section

Base Module


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?

5.3     JavaScript methods and variables

5.3.1     Prefixing:

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

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






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

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

Powered by eList eXpress LLC