[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsrp][markup] Second conference call (Updated Minutes)
Just a minor modification added to the minutes regarding Rich comment : only advanced use case in WSIA can't process HTML. (See attached file: Minutes Markup 04222002.htm)(See attached file: Minutes Markup 04222002.doc) 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 42Title: 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? 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. · 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). |
Attachment:
Minutes Markup 04222002.doc
Description: MS-Word document
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC