[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsrp][markup]Markup document (updated revision)
Hi All, Here are the latest version of the Markup master document based on the latest concall Regards, (See attached file: WSRP Markup.doc)(See attached file: WSRP Markup.htm) David Taieb Advisory Software Engineer Lotus Software, IBM Software group One Rogers Street Cambridge, MA 02142 Tel : (617) 693 5819 Fax : (617) 693 5542
Attachment:
WSRP Markup.doc
Description: MS-Word document
WSRP
Markup, Style and Rewriting Specifications Version 1.2 Revision History
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 2 3.1 Problem
description 2 3.2 HTML 2 3.2.1 HTML
validation rules 2 Disallowed 2 Discouraged 2 3.3 XHTML
Basic 2 3.3.1 XHTML
Basic Validation rules 2 Disallowed 2 Discouraged 2 3.4 Other
Markups 3 3.5 Markup
Fragment decomposition 3 4. Secure resources: 3 4.1 Problem
Description 3 4.2 Proxy 3 4.3 Caching
the resource 3 5. URL Rewriting 3 5.1 Problem
Description 3 5.2 Rewriting
scenarios 3 5.2.1 At the
Producer side 3 5.2.2 At the
aggregator side 3 5.3 Mechanism
used to demarcate URLs 4 6. Namespacing/Prefixing 4 6.1 Problem
Description 4 6.2 Named
attributes 4 6.3 JavaScript
methods and variables 4 6.3.1 Prefixing: 4 Is there any reason to treat them any differently from Named
attributes? 4 6.3.2 Cross
portlet JavaScript methods and variables: 4 1. Goals of this documentTo 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 Themes2.1 Problem DescriptionAs WSRP services are consumed, we need a mechanism to provide a consistent look and feel across all the aggregated portlets. 2.2 CSS classes:Since WSRP classes are a subset of the WSIA classes, WSRP will eventually use a WSIA namespace using “wsia-“ as a prefix CSS classes submitted by WSUI and IBM WPS:
3. Markup Fragment Rules3.1 Problem descriptionBecause 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 HTMLBecause disallowed tags might potentially have an impact on other portlets or even break the whole aggregated page, its inclusion will invalidate the whole markup fragment which will be replaced by an error message. 3.2.1 HTML validation rules
3.3 XHTML Basic3.3.1 XHTML Basic Validation rules
3.4 Other Markups… 3.5 Markup Fragment decompositionProposition 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. 4. Secure resources:4.1 Problem DescriptionThe client might not always have direct access to resources (like java applets, images, etc…) embedded in the portlet because of network topology reason for instance.. Therefore, after the link URI is being rewritten to point to the aggregator, the aggregator must provide a transparent mechanism that ensures availability of the resource by acting as a proxy between the user and portlet. The aggregator might also decide to proxy a cached version of the resource. Question: How does the portlet indicates that a resource needs to be proxied (especially for these URL that are dynamically generated using JavaScript). 4.2 ProxyThe aggregator proxies the request from the client to the remote portlet and proxies back the resource to the client. Note: we need to make sure that security, privacy and access control are not compromised during the proxying process. 4.3 Caching the resourceThe aggregator caches the resource from the remote portlet and directly serves it to the client. Question: what standard do we apply for determining that a resource has expired? 5. URL Rewriting5.1 Problem DescriptionURLs 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. 5.2 Rewriting scenarios5.2.1 At the Producer sideThe Aggregator sends a prefix with the request that the producer will use to do the URL boundary demarcation. The aggregator then parses the markup looking for the prefix it provided. If no prefix is provided, the portlet will use a standard one defined in this spec. 5.2.2 At the aggregator sideThe
aggregator sends the URL prefix to use to the remote portlet, allowing it to do
the rewriting itself on all the necessary URL. However, the remote portlet can
choose not to rewrite all the URLs and will use the same algorithm as in 5.2 to
demarcate the URL. It is then up to the aggregator to identify and rewrite all
the remaining URLs using the prefix used by the producer. 5.3 Mechanism used to demarcate URLsThe producer uses an escape sequence that contains all the parts of the URLs followed optionally by some parameters. The aggregator then searches this sequence and reconstructs the URL using the correct URL prefix. Advantages: this method is parsing efficient and should be easy to implement. TODO: more details about the algorithm 6. Namespacing/Prefixing6.1 Problem DescriptionAggregating multiple portlet from different sources can potentially result in naming conflicts for various types of elements: named attributes, JavaScript functions and variables, etc… 6.2 Named attributesNamed 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? 6.3 JavaScript methods and variables6.3.1 Prefixing:Is there any reason to treat them any differently from Named attributes?6.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… |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC