[wsrp][markup] Second conference call (Minutes)

[David Taieb/Cambridge/IBM <david_taieb@us.ibm.com>]

Hi all,
      Here are the minutes for yesterday second conference call for the
Markup subcommittee.

(See attached file: Minutes Markup 04222002.doc)(See attached file: Minutes
Markup 04222002.htm)

Thanks

David Taieb
Advisory Softwary Engineer
Lotus Software, IBM software group
One Rogers Street
Cambridge, MA, 02142
Tel : (617) 693 58 19
Fax : (617) 693 55 42

Attachment: Minutes Markup 04222002.doc
Description: MS-Word document

Title: Minutes : Markup Sub-committee Conference Call, April 23, 2002

Minutes : Markup Sub-committee Conference Call, April 23, 2002

 

Introduction:

A proposition was made at the last WSIA face to face to create a join Markup subcommittee with this group to look after WSIA specific issues but we realize that this committee will already address most of the problems. A subcommittee would form and later join with us.

 

 

·        Markup:

o       Should we standardize on XHTML and not support plain (sometime not parsable) HTML?
-Protocol should be markup agnostic.
-Markup validation rules should support HTML because of the existing HTML user base and legacy HTML application base.
-Rich mentioned that WSIA can’t take HTML, we need to make sure that HTML and XHTML have different defined content types in the metadata.
-Consensus: we should support both markup but they have to be clearly differentiated in their metadata description, as their consumption will be different.

o       Markup validation: should we differentiate between disallowed tags (the one that can break the page) and discouraged tags (the one that are of no use but don’t break the page)? For example: STYLE/LINK tags? According to HTML documentation, they can only occur in the HTML Header, need to investigate if their occurrence in portlet fragment will affect the page.

o       Aggregator layout: TABLE vs. IFRAME. Because IFRAME can be considered mini-browsers containing full web applications, they will be considered outside the scope of WSRP.

o       Should portlets be aware of their surrounding tags? Thomas suggested that protocol should be agnostic of aggregation type, we would have to define the least common denominator set of allowed tags.

o       Focus will be on HTML and XHTML basic first. VoiceXML and WML will be left for the end.

o       How do we deal with protected resources (like images, signed java applets, etc…) that have direct links to the client who might not be able to access them directly because of firewall settings for example? There is two classes of resources: cachable and proxied. This information should be part of the protocol and will affect the behavior of the consumer as well as the way URL are being rewritten. In some cases the portal might choose not to rewrite them at all if it determines that the client has direct access to the producer. It can do so by recognizing their prefix (who should be different from the one used in regular URLs) and removing them altogether leaving the original URL instead.

o       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.
Michael suggested that this standard base set depends on the content type (some section might make sense for a markup language but not for others).

·        JavaScript:

o       Because JavaScript items can be referenced from other JavaScript code (or HTML attributes as well) it is difficult to rewrite it well without breaking the portlet application.

o       Mention has been made that the problem become even more complex if the portlet uses shared resources like including JS files.

o       Two possible solutions: the consumers locate the JavaScript items and rewrite them or the consumer sends the prefix information and let the producer rewrite. Depending on the case, it might be required that the consumer do the rewriting and in some other cases the producer has access to information that makes it easier to do the rewriting. The concern becomes that allowing both scenarios to take place by negotiations between the two parties, will complicate dramatically the protocol. Michael suggested that to lighten the negotiation, may be the consumer should make available rewriting information to the producer and let it choose what to rewrite. The consumer would then do some parsing to determine what needs to be rewritten (by doing a simple text search on the prefix put by the producer on items it didn’t want to rewrite).

o       David will write a table to capture pro and cons for each alternative (Including the one proposed by Sasha).

·        URL Rewriting:

o       Sasha raised the question whether the prefix scheme is robust enough for URL rewriting?  Carsten explained another alternative that uses escape sequences from the portlet markup that contains all the parts of the URL followed by some parameters. The consumer then reconstructs this escape sequence.

o       Gino remarks that this would make the portlet not workable in a standalone mode. Consensus was reached that working stand alone shouldn’t be a requirement.

·        Namespace encoding:

o       Pretty much the same as URL rewriting.

o       This group will define a list of all the things that need to be encoded.

·        Visual Styles:

o       Include in document css classes from WPS.

o       Final naming should not be made portal specific but protocol specific (something like WSRP_XXXX or WSIA_XXXX).