W3C Workshop on
Device Independent Authoring Techniques

Authoring Device Independent
Portal Content

Luu Tran
Sun Microsystems, Inc.


Web portals integrate and aggregate information and applications.  Several standards are emerging from the Java Community ProcessSM (JCP) [1] and the Organization for the Advancement of Structured Information Standards (OASIS) [2] that will define how portal servers operate and how portal content is delivered.  Authoring content for portals typically involves developing HTML [3].  However, authoring content for a device independent portal requires special attention.  In particular, authors need to consider the relationship between device independence and the personalization and aggregation features of a portal server when developing device independent portal content.

Web Portals

A web portal is an entry point to a set of resources that an enterprise wants to make available to the portal's users. For some consumer portals, the set of resources includes the entire Web. For most enterprise portals, the set of resources includes information, applications, and other resources that are specific to the relationship between the user and the enterprise.  Commercial portals often provide membership management, personalization, aggregation, security, integration, and search services.

Several standards bodies have begun work on developing portal standards.  The JCP [1] has established a Java Specification Request (JSR) 168 [4] to define a set of Java APIs for Portal computing addressing the areas of personalization, presentation and security.  This API is intended to be used to develop portlets that are meant to be aggregated.  OASIS [2] has established a Web Services for Remote Portals (WSRP) Technical Committee (TC) [5] to define an XML and Web services standard that will allow the plug-n-play of visual, user-facing Web services with portals or other intermediary Web applications.  WSRP defines a set of rules that portlet generated markup should follow so as to not  break the aggregated portal page.

A device independent portal is one that can be accessed from several different web access mechanisms or devices.  A device independent portal server provides the platform for deploying device independent portals.  Portal servers often invoke pluggable components, known as portlets, to produce content.  Authoring device independent portlets often involves understanding and leveraging two primary features of a portal server: personalization and aggregation.

Authoring Personalizable Content

Personalization is a portal server feature which allows portal content to be personalized or tailored for a particular user.  Personalization can be user or system driven.  User driven personalization often involves a user selecting preferences or setting configuration values that explicitly determine what content is displayed or how that content is formatted.  An example of user driven personalization is a user selecting various portlets, e.g. weather, stock quotes, and then configuring those portlets, e.g. setting a location for weather or stock symbols for stock quotes.  System driven personalization often involves a process by which content is selected or generated based implicitly on either user or system level configuration.  An example of system driven personalization is displaying an advertisement, e.g. from a technology company, on the portal of users who might have interest, e.g. who have selected technology company stocks in their stock quotes portlet.

Authoring device independent portlets often involves identifying the aspects of a portlet that are personalizable and the associated personalization parameters.  Personalization parameters are either device independent or device specific and either portlet independent or portlet specific.  For example, a user's name is both device independent and portlet independent, while the number of mail messages to display on a given device is both device specific and portlet specific.  We have found that a useful authoring technique is to group together portlet independent parameters so they can be stored and configured in one place and shared across multiple portlets.  Likewise, we have found that another useful authoring technique is to group together device independent parameters so they can be used for delivery to multiple devices.

Authoring Aggregated Content

Aggregation is a portal server feature which allows portal content from various disparate sources to be combined and presented to a user in a single response.  This is done by invoking portlets to produce content that becomes a fragment of a document, e.g. an HTML [3] table cell or a WML [6] card.  The portal server wraps the fragments with the necessary markup, e.g. table headers, buttons, links, etc., and combines the result into a single document that is sent as a response to the access mechanism.

Authoring device independent portlets requires special consideration of the limitations imposed by the aggregation process.  Because a portlet returns only a fragment and does not have control over the entire response, the portlet author must be aware of how the portal server will wrap the fragment.  For example, will the portal server supply the HTML [3] <td></td> tags or the WML [6] <card></card> tags, or will the portlet be responsible for supplying those?  Also, because the fragment is combined with other fragments, the portlet usually only has available to it a fraction of the maximum response size of the access mechanism.  The portlet author must therefore be careful not to produce too much content, or the portal server will be forced to either break up or omit the portlet's content.

We have found it a useful authoring technique to break up portlet content into multiple units for limited devices.  The units consist of a minimal summary screen that references one or more other screens for detailed content.  The references could be to other cards in a WML [6] deck, or to URIs to request another response.  An added benefit to breaking up portlet content into these units is that several units can be reused for multiple devices.  Only when a particular unit of content requires markup for a specific device does an author need to supply an alternate unit to be used for other devices.  With this technique, the granularity of device independence becomes much finer and more tractable.

Sun ONE Portal Server

The Sun ONE Portal Server [7] is a complete portal platform for deploying robust business-to-employee, business-to-business, and business-to-consumer portals. The Sun ONE Portal Server provides the services required to build portal sites, including user and community management, personalization, aggregation, security, integration, and search.  With the Mobile Access add-on, the Sun ONE Portal Server addresses the personalization and aggregation aspects of developing and deploying device independent portals.


[1] JCP: "The Java Community Process(SM) Program", http://www.jcp.org/
[2] OASIS: "Who We Are", http://www.oasis-open.org/who/
[3] W3C: "HTML Home Page", http://www.w3.org/MarkUp/
[4] JCP: "JSR 168 Portlet Specification", http://www.jcp.org/jsr/detail/168.jsp
[5] OASIS: "Web Services for Remote Portals (WSRP) TC", http://www.oasis-open.org/committees/wsrp/
[6] OMA: "Wireless Markup Language", http://www1.wapforum.org/tech/documents/WAP-238-WML-20010911-a.pdf
[7] Sun Microsystems, Inc.: "Sun ONE Portal Server", http://wwws.sun.com/software/products/portal_srvr/home_portal.html