Markup Sub-committee Conference Call, April 5, 2002

Introductions
Carsten thinks some of the tasks we will address might already be done in the JSR168, Porlet API. Thomas and Mike F both say that JSR168 will be concerned with mainly with Java language specific APIs and will not deal with markup issues.
We decide to go over and summarize the topics that this sub-committee will deal with.

CSS will be used for the HTML markup. Thomas said that other markup languages haven’t got concepts analogous to CSS so we can’t define anything for them.
It was suggested that we should collect a list of styles from portal vendors that they currently use today and abstract a common set from there. WSIA has pushed this task off as they are too busy but they’ve already collected examples from WSUI and from the IBM Portal Server.
Thomas suggested that these styles would appear in an appendix of the spec.
David T. asked if we should support any Microsoft specific behaviours or IE-only extensions. But most of these are just extensions of CSS anyway.

Because each markup language will have a different set of restricted tags, we will be considering markup languages in this order of priority:

Mike F: Given our aggressive schedule, it might only be feasible to define rules for HTML and we will work on the rest time permitting.
The IBM demo implementation of WSRP has the following list of restricted tags:

Carsten brought up the notion that portlets might need to introduce tags and content that can only occur in a global scope. He believes we should specify that portlets return their markup in following 3 sections seperated by known tokens

Mike F: Instead of a single part return message that contains tokens, why not use a 3 part return message as supported by WSDL.
An issue was brought up that currently many stacks do not support a multi-part return message and this might be an issue.
Mike F: We shouldn’t be worried about current implementations, as long as there is support in WSDL.
We need to figure out what the need is for the beginPage and endPage sections.
Thomas brought up the use case of allowing portlets the ability to write their own cookies into the headers that are returned to the browser. The problem is that cookies have the domain of the server they run on and since these portlets are remote, that server won’t be the same as the actual aggregator.
ACTION: Thomas will submit a use-case for why we should allow portlets to specify markup for the beginPage and endPage sections.

Who should do it? The aggregator or the provider?
Carsten believes the aggregator should do the rewriting since it has full knowledge of the different portlets it is aggregating and how their actions should be routed.
The WSIA has made a case for both the provider and the aggregator doing the rewriting under different circumstances.
ACTION: Start a list of advantages and disadvantage to either side handling the rewriting of markup.
The spec will be defining the prefixes that are used to identify places where rewriting needs to occur. It will be left to the implementation to determine how to find these prefixes and what needs to be written for each.
Carsten pointed out that when defining the prefixes, we should take care to define them in such a way to make it easy for implemenations to efficiently find them; ie: using long enough strings that have a small likelihood of occurring “naturally” in the markup.
A list of items that require re-writing was proposed including:

Actually, these are not necessary. We only need to define the types of re-writing that need to occur, not the actual elements. It will be up to implementations to determine how the re-writing for each type should be done.

ACTION: Currently, the following 2 types of rewriting have been put forward; we need to discuss these and see if there are other types of rewriting that need to be supported.

We will need to provide a unique prefix for each type of rewriting that we support, this way the aggregator will know what type of rewriting needs to occur when each prefix is found.
Namespaces should still be valid even without rewriting/encoding them. It will be left up to the aggregator as to whether or not namespaces should be encoded.

David also suggested that this sub-committee be in charge of providing some guidelines/best practices for remote portlet developers.
Thomas suggests that this is outside of the scope of this sub-committee and is not something that should be part of the spec as it is best left as a separate document.