Markup Sub-committee Conference Call, April 5, 2002

Markup Sub-committee Conference Call, May 8, 2002

Attendees: Gino Filicetti, David Taieb, Rich Thompson, Jane Dynin, Jeff Broberg, Lothar Merk, Carsten Leue

Jeff suggested that we should use a WSIA namespace for the CSS classes that we are defining since these classes will be used in WSIA as well
Rich thinks we should have two namespaces, and envisions things moving back and forth between the WSRP namespace and the WSIA namespace as they are designed and discussed.
David asked if we need to provide default values for these styles. The consensus was that default values will NOT be part of the spec and instead will be left up to the implementation.
Rich asks whether all producers NEED to use style sheets or CAN use style sheets.
Consensus was reached that we should use a WSIA namespace for all of our CSS class names, using “wsia-“ as a prefix to the class name.
Jeff is going to contribute more styles to our current list.
ACTION: Consolidate the list the styles and rename them using the appropriate namespace (“wsia-“) after Jeff’s contribution is made.

The “problem” tags in both HTML and XHTML Basic were categorized into Disallowed and Discouraged subsets as follows:
HTML:
    Disallowed: base, body, frame, frameset, head, html, title
    Discouraged: link, meta, style
XHTML
    Disallowed: base, body, head, html, title
    Discouraged: link, meta
Carsten wants us to be absolutely sure that the discouraged tags will really work inside of the <body> tag in all (most common) browsers.
Question, does the inclusion of a DISALLOWED tag invalidate the whole markup fragment?
Consensus was that yes, this is true… however, we don’t want to require consumers to parse markup fragments looking for disallowed tags.
Jeff: It is not a requirement for the consumer to parse the output of the producer; however, we do want to leave room for this if a consumer wants to. Do we want to provide a mechanism for the consumer to inform the producer that an error occurred?
We should spec that its not required to parse the markup and leave the rest open to interpretation.
Rich: This is a definition of conformance; does not dictate any behaviours and that’s how it should be specified.

The two scenarios (see agenda) envisioned can actually be merged into one.
Carsten: All we need to say is that secure resources are accessed through the consumer by way of all links being rewritten to point back to the consumer, and then the consumer can choose whether to do a straight proxy or cache the resources if need be.
Rich, how does the producer indicate that a resource needs to be proxied?
Jeff, Carsten, Gino… the consumer is in a better position to determine whether a resource needs to be proxied for a particular client.
Rich: Need to be careful when talking about the proxying capability and require that the same security needs to be applied with respect to privacy and access control that the rest of the system applies.

Same 3 scenarios (see agenda) were considered. The 2^nd scenario is seen as the most ideal and easiest to implement.
Jeff suggested that scenario 1 and 2 could be combined where the consumer could OPTIONALLY send a prefix, and if it wasn’t sent, the producer would use the standard one.
Carsten: Then there wouldn’t be a reason to have a standard prefix.
Carsten: The advantage of having a standard prefix is that the search and replace code could be written once and made into a standard library.
3^rd scenario was dismissed outright as being technically infeasible.
Rich: A deterministic heuristic does not exist for finding URLs that are dynamically constructed in Javascript.

An escape sequence is used that can be searched for and replaced by the correct rewritten URL.
Explicit tags are put into the markup to indicate URLs that need to be rewritten. And then the markup will have to be parsed in an XML parser to find the necessary spots to do the rewriting.

Consensus was reached that the escape sequence alternative would perform better and be easier to implement.
Rich: A 4^th scenario brought up in the WSIA Embedded use case was to have the aggregator tell the remote portlet URL prefix to use, and have the remote portlet rewrite all necessary URLs and then return the markup which would be ready for immediate inclusion in the page.
Rich: A combination of scenarios 2 and 4 can be where a producer can indicate whether is CAN rewrite the URLs if chosen to do so (scenario 4). But the Consumer is REQUIRED to rewrite the URL if the Producer will not (scenario 2).

Jeff: Will look into asking one of his team members (Chris Braun) who is involved in the JSR169 Markup subcommittee and has been following the WSRP committees closely if he’d be interested in taking up the leadership duties of the group. He’ll get in contact with Gino directly.
No one else on the call was interested in the job.