Portal Specifications

Java™ Portal Framework, Enterprise Edition Specification ("Specification")

Version: 1.0

Status: Preliminary Release

Release: 2/16/2000

880 Apollo St, Suite #237, CA 90245, U.S.A.

NOTICE.

This Specification is protected by copyright and the information described herein may be protected by one or more U.S. patents, foreign patents, or pending applications. Except as provided under the following license, no part of this Specification may be reproduced in any

form by any means without the prior written authorization of JA-SIG and its licensors, if any. Any use of this Specification and the information described herein will be governed by these terms and conditions and the Export Control and General Terms as set forth in JA-SIG's website Legal Terms. By viewing, downloading or otherwise copying this Specification, you agree that you have read, understood, and will comply with all the terms and conditions set forth herein.

JA-SIG hereby grants you a fully-paid, non-exclusive, non-transferable, worldwide, limited license (without the right to sublicense), under JA-SIG’s intellectual property rights that are essential to practice this Specification, to internally practice this Specification solely for the

purpose of creating a clean room implementation of this Specification that: (i) includes a complete implementation of the current version of this Specification, without subsetting or supersetting; (ii) implements all of the interfaces and functionality of this Specification, as defined by JA-SIG, without subsetting or supersetting; (iii) includes a complete implementation of any optional components (as defined by JA-SIG in this Specification) which you choose to implement, without subsetting or supersetting; (iv) implements all of the interfaces and functionality of such optional components, without subsetting or supersetting; (v) does not add any additional packages, classes or interfaces to the "java.*" or "javax.*" packages or subpackages (or other packages defined by JA-SIG); (vi) satisfies all testing requirements available from JA-SIG relating to the most recently published version of this Specification six (6) months prior to any release of the clean room implementation or upgrade thereto; (vii) does not derive from any JA-SIG source code or binary code materials; and (viii) does not include any JA-SIG source code or binary code materials without an appropriate and separate license from JA-SIG. This Specification contains the proprietary information of JA-SIG and may only be used in accordance with the license terms set forth herein. This license will terminate immediately without notice from JA-SIG if you fail to comply with any provision of this license. JA-SIG may, at its sole option, terminate this license without cause upon ten (10) days notice to you. Upon termination of this license, you must cease use of or destroy this Specification.

TRADEMARKS.

No right, title, or interest in or to any trademarks, service marks, or trade names of JA-SIG or JA-SIG's licensors is granted hereunder. JA-SIG, the JA-SIG logo, Java, Jini, JavaServer Pages, Enterprise JavaBeans, Java Compatible, JDK, JDBC, JavaBeans, JavaMail, Write

Once, Run Anywhere, and Java Naming and Directory Interface are trademarks or registered trademarks of JA-SIG. in the U.S. and other countries.

DISCLAIMER OF WARRANTIES.

THIS SPECIFICATION IS PROVIDED "AS IS". JA-SIG MAKES NOREPRESENTATIONS OR WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR APARTICULAR PURPOSE,

OR NON-INFRINGEMENT THAT THE CONTENTS OF THE SPECIFICATION ARE SUITABLE FOR ANY PURPOSE OR THAT ANY PRACTICE OR IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS,

TRADE SECRETS OR OTHER RIGHTS. This document does not represent any commitment to release or implement any portion of this Specification in any product.

THIS SPECIFICATION COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS. CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION HEREIN; THESE CHANGES WILL BE INCORPORATED INTO NEWVERSIONS OF THE SPECIFICATION, IF ANY. JA-SIG MAY MAKE IMPROVEMENTS AND/OR CHANGES TOTHE PRODUCT(S) AND/OR THE

PROGRAM(S) DESCRIBED IN THIS SPECIFICATION AT ANY TIME. Any use of such changes in the Specification will be governed by the then-current license for the applicable version of the Specification.

LIMITATION OF LIABILITY.

TOTHE EXTENT NOT PROHIBITED BY LAW, IN NOEVENT WILL JA-SIG OR ITS LICENSORS BE LIABLE FOR ANY DAMAGES, INCLUDING WITHOUT LIMITATION, LOST REVENUE, PROFITS OR DATA, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL,

INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED ANDREGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF OR RELATED TOANY FURNISHING, PRACTICING, MODIFYING OR ANY USE OF THE SPECIFICATION, EVEN IF JA-SIG

AND/OR ITS LICENSORS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

You will indemnify, hold harmless, and defend JA-SIG and its licensors from any claims arising or resulting from: (i) your use of the Specification; (ii) the use or distribution of your Java application, applet and/or clean room implementation; and/or (iii) any claims that

later versions or releases of any Specification furnished to you are incompatible with the Specification provided to you under this license.

RESTRICTED RIGHTS LEGEND.

Use, duplication, or disclosure by the U.S. Government is subject to the restrictions set forth in this license and as provided in DFARS 227.7202-1(a) and 227.7202-3(a) (1995), DFARS 252.227-7013(c)(1)(ii)(Oct 1988), FAR 12.212(a) (1995), FAR 52.227-19 (June 1987), or FAR

52.227-14(ALT III) (June 1987), as applicable.

REPORT.

You may wish to report any ambiguities, inconsistencies, or inaccuracies you may find in connection with your use of the Specification ("Feedback"). To the extent that you provide JA-SIG with any Feedback, you hereby: (i) agree that such Feedback is provided on a non-proprietary and non-confidential basis and (ii) grant JA-SIG a perpetual, non-exclusive, worldwide, fully paid-up, irrevocable license, with the right to sublicense through multiple levels of sublicensees, to incorporate, disclose, and use without limitation the Feedback for any purpose related to the Specification and future versions, implementations, and test suites thereof.

Contents >>>

Introduction

A portal is a collection of services targeted for a specific group

Enterprises today need to extend their reach, reduce their costs, and lower their

response times by providing easy-to-access services to their students,

faculty, staff, alumni and friends. Typically, applications that provide these services

must combine existing Enterprise Information Systems with new business functions that deliver services to a broad range of users. These services need to be:

Highly available, to meet the needs of today’s electronic campus.

Secure, to protect the privacy of users and the integrity of the enterprise.

Reliable and scalable, to insure that transactions are accurately and promptly processed.

In most cases, these services are architected as multi-tier applications. A middle-tier

that implements the new services needs to integrate existing systems with the

business functions and data of the new service. The service middle-tier shields

first-tier clients from the complexity of the enterprise and takes advantage of

rapidly maturing web technologies to eliminate or drastically reduce user

administration and training while leveraging existing assets. The Java™ 2 Platform, Enterprise Edition (J2EE) reduces the cost and complexity of developing these multi-tier services, resulting in services that can be rapidly deployed and easily enhanced as the enterprise responds to competitive pressures.

The JA-SIG Portal Framework Specification follows the J2EE philosophy and is intended to integrate with that programming model. Refer to the Java 2 Platform Enterprise Edition Specification and The J2EE Application Programming Model for detail.

The JA-SIG Portal Framework Specification defines a sub-system that resides within the Web Container. It acts as a shell, managing its clients: channels, applications and primitives such as History, Help, Links, Logos and so on.

The purpose of the Portal Framework is to provide Higher Education Institutions with a Web interface that meets the needs of these institutions. These needs are:

Provide a community interface that directly reflects the institution
Provide a security model that manages access to the channels, applications and publications of the institution
Provide a publish/subscribe model that allows the citizens of the institution to both use and provide content
Provide a mechanism that allows the institution to define itself in terms of its departments, schools, organizations and bodies
Provide control over the content of the institution’s electronic campus

The JA-SIG Portal Framework Specification is the work of many people.

Overview

The Portal Framework follows the container — component model outlined by the J2EE specification. The Portal Framework is a little different in that it is both a component and a container. Specifically, it is a component running in a Web Container and is a container that runs components such as a channel, an application or some publication. When we say Portal Container we mean the software that sits between the Web Container and the channel and application components.

The Portal Framework will execute in any Servlet 2.1 compliant Web Server (container).

Architecture

The portal architecture can take advantage of the J2EE services provided by the Web Container. Thus, servlets may use JMS, JTA and the like as they are available. No restrictions are imposed by the portal.

The J2EE specification makes these comments about applets, servlets and JSP pages:

— Applets are GUI components that typically execute in a web browser, but

can execute in a variety of other applications or devices that support the

applet programming model. Applets can be used to provide a powerful

user interface for J2EE applications. (Simple HTML pages can also be used

to provide a more limited user interface for J2EE applications.)

— Servlets and JSP pages typically execute in a web server and respond to

HTTP requests from web clients. Servlets and JSP pages may be used to

generate HTML pages that are an application’s user interface. They may

also be used to generate XML or other format data that is consumed by

other application components. Servlets, and pages created with the

JavaServer Pages™ technology, are often referred to collectively in this

specification as "web components." Web applications are composed of web

components and other data such as HTML pages.

The Portal Framework Specification adds a layer that provides these additions:

security
repository
personalization
statistics
search
publish
subscribe
availability index
common look-and-feel
institutional model
interfaces

portal layout
application interface

XML
EJB
other

channel

java
RSS

artifacts
administration

alerts

Figure 1. Refer to the J2EE Specification for more detail surrounding this configuration

Figure 2. Basic portal layout

A note on Applications. Essentially, applications are a group of channels that are managed by the tabbing (menu) system. It will be possible to use the portal to drive a single application. This entails using a subset of the portal capabilities. Commonly, the portal will point to applications and these applications then reuse portal constructs to get the job done.

Security

The Portal Framework provides authentication and session management, as well as other security services. These ensure that only authorized principals can access the information and services managed by the portal.

Administrators need to be able to define roles for individuals and groups within the institution. These roles define the topics or categories users can view, channels they can subscribe to, the functions they can use and the data they can view.

Security implementations must be "pluggable". Authentication can then be performed according to the needs of the given institution: users authenticate via a username/password combination or, optionally via a secured page (via SSL).

Resources can be secured by ascribing roles. These roles must then match a role of the user in order to obtain access.

It is also possible to manage "public" resources, where a login is not required at all.

Entire categories can also be assigned roles, providing for control over the "views" of resources that are available to users. This is left to the implementor.

All user access is by means of a secured login process (SSL optional) which identifies a user’s role set.

Repository

The heart of a portal is the repository, which contains data about information objects, users, groups, and channels.

Object properties:

Type. Is the object a component, document, link, channel etc?
Topic. To which classification does the object belong?
Description.
Format.
Location. Where is the object stored?
Roles.
Publisher
Release notes.

We do not specify persistent storage. It is possible to implement using an object database, a relational database or possibly some hybrid where each entry is an XML document.

User profiles specify the following properties:

User ID
Profile. The individual profile shows what groups individuals belong to.
Subscription property defines the objects or channels that an individual has subscribed to.

Note: Profile information may be associated with the Security mechanism. It is reasonable to, for example, implement Principals, Roles and Profiles in LDAP.

The repository of resources that are file-based (HTML etc) can be stored on any appropriate device, or divided among a number of such devices. The resources are normally stored outside of the normal web content area served by the web server application, preventing access to the resource other than through the portal. The resource index is stored in a group of tables in a relational database, providing easy reporting and manipulation through standard SQL.

Resources are organized into categories, and each category may have a "parent" defined. This allows hierarchies to be constructed to any depth. Resources are then assigned one or more category - allowing the same resource to be organized in more than one way, for different purposes, but avoiding duplication of the resource itself.

Resources are managed by the repository. They will in most cases be distributed throughout the institution (on departmental machines and so on). This generates security issues that still need to be addressed.

Archiving needs to be added.

Personalization

The user's identity becomes the basis for the personalized experience of interacting with the portal. The user acquires attributes over time. These attributes enable the portal to provide components that match these attributes. Attributes are similar to roles and may be managed in the same way — also see Profiles

Access to resources can also be tracked and audited. When a particular resource is updated it should be possible to indicate that to its subscribers.

Statistics

The portal will map the content and selections of each user portal instance to a statistical record (- an XML record in a column for that user). This statistical record is then used to provide the user with components of interest. Note that the publisher associates characteristics to the published component.

TBD

Publish

Working in concert with user roles, the publish facility allows users to publish objects into the repository. This is done by matching the roles of the user to the roles associated with the Publish service.

A content manager should make it easy for the authors of content to get their material onto the web site without conflicting with other authors, and should at the same time make it easy for the user of the web site to get to the content they require (and have access to). Authors can upload new content using the browser. Resources must be able to be uploaded one at a time or in bundled groups. Version control and update locking must be supported for multiple authors accessing the same resource, and any number of previous revisions of a resource can be maintained online.

The publisher must assign attributes to the published document. For example: whitepaper; physics; astronomy. This will enable the Statistics module to map a user to interests. This, in turn, allows the system to present the user with choices that are likely to be of interest.

The Portal Framework will enable files to be uploaded from an authorized user's PC directly to the system. Both text (HTML, XML, etc) and binary formats can be uploaded in this way. Downloading will work similarly.

Publish must be able to distribute the files into their appropriate resource locations. This allows the maintenance of content to be put into the hands of the appropriate party, and relieves IT from the burden of becoming involved whenever new content is required, without opening the opportunity for a user to publish content incorrectly and cause system failures - which can be the case with normal HTML pages. At the same time, advanced access management on resources can be used to ensure that only authorized content is published. Designated contributors are empowered to maintain their online content. Access will be based on roles as specified by J2EE.

In addition to being notified when new content is available, users of the portal should also be able to subscribe to content — with new revisions of the content automatically emailed to the user when available.

The subscription lists are stored in the relational database, for easy maintenance and reporting (security permitting). We expect that a java DB such as HypersonicSQL will be used to manage these data.

The personalized home page should also provide users with, for example, a number of subscribed channels.

Categories form the basis for the user's views of resources - where different users can see different organizations of the same content. Each user can see resources organized according to a structure appropriate to their needs: for example, faculty might see the course materials for their classes whereas the student might see the same course materials for the classes they are taking..

Categories go to n-levels. Categories can be used, for example, to reflect the organization and department organization and to reflect alternatively any other way you want to organize resources. Resources can be categorized into multiple categories so that the same resource, such as a report, can be made available under more than one content heading.

Components — not a part of the Portal Framework

Calendar
Chat
E-mail
News
Contact/Address book
Voting/Polling/Survey/Test
Collaboration/Sharing
Document management
Applications

Interfaces

The most important aspect of the portal specification is the interface. These, along with the documentation on how to use them, will allow the citizens of the institution to publish content without having to deal with the internal working of the portal engine.

Some interfaces:

portal layout

Document Type Definition

<?xml encoding="US-ASCII"?>

<!ELEMENT layout (tab+) >

<!ATTLIST layout

bgcolor CDATA #REQUIRED

fgcolor CDATA #REQUIRED

activeTab CDATA #REQUIRED

tabColor CDATA #REQUIRED

activeTabColor CDATA #REQUIRED

channelHeadingColor CDATA #REQUIRED>

<!ELEMENT tab (column+) >

<!ATTLIST tab

name CDATA #REQUIRED>

<!ELEMENT column (channel*)>

<!ATTLIST column

width CDATA #REQUIRED>

<!ELEMENT channel (parameter*)>

<!ATTLIST channel

minimized (true|false) "true"

class CDATA #REQUIRED>

<!ELEMENT parameter EMPTY>

<!ATTLIST parameter

name CDATA #REQUIRED

value CDATA #REQUIRED>

Sample

<?xml version="1.0"?>

<!DOCTYPE layout SYSTEM "D:\Projects\ibs\portal\source\xml\layout\layout.dtd">

</channel>

<parameter value="fps>18^a1>12500^pixd>29^pixangle>5^radius>26^roty>-4^rotx>0^rotz>0.401^irotx>0^iroty>0^irotz>0^style>1^color>#00FF66^bgcolor>#000000^12hour>0" name="params"/>

</channel>

<parameter value="cabbase>ScorePost.cab^bgcolor>#336699^text>#FFFFFF^data>/cgi/scoretracker/databuffer.dll?/scoretracker/scorepost/data/all.dat^ad data>/ad/scorepost/nhl.txt^target>_top^delay>3500^data time>30000^inactive data time>300000" name="params"/>

</channel>

</column>

</channel>

</column>

</channel>

</channel>

<parameter value="cabbase>MegaTicker.cab^station>KABC" name="params"/>

</channel>

</column>

</tab>

</channel>

</column>

</tab>

</channel>

</column>

</channel>

</column>

</tab>

</layout>

application interface

Sample for XML-RPC request — too limited

<?xml version="1.0"?>

<methodName>examples.getStateName</methodName>

<param>

</param>

</params>

</methodCall>

response

<?xml version="1.0"?>

<param>

<value><string>South Dakota</string></value>

</param>

</params>

</methodResponse>

Sample for SOAP (Simple Object Access Protocol) from Microsoft

In SOAP, the mechanism used for all communication is HTTP [1]. A central design goal of SOAP is that it be usable strictly on top of today's deployed World Wide Web infrastructure. That means SOAP has to work amid the various levels of HTTP implementation, the active use of firewalls and proxies, and so on. Some aspects of SOAP, such as the permitted use of HTTP methods beyond those of classic HTTP, are designed to anticipate, and thus make use of, some evolution and improvement in this base, but nothing in SOAP can require such fundamental changes in order for SOAP to function.

POST /StockQuote HTTP/1.1

Host: www.stockquoteserver.com

Content-Type: text/xml

Content-Length: nnnn

SOAPMethodName: Some-Namespace-URI#GetLastTradePrice

<SOAP:Envelope xmlns:SOAP="urn:schemas-xmlsoap-org:soap.v1">

<SOAP:Body>

<m:GetLastTradePrice

xmlns:m="Some-Namespace-URI">

</m:GetLastTradePrice>

</SOAP:Body>

</SOAP:Envelope>

response

HTTP/1.1 200 OK

Content-Type: text/xml

Content-Length: nnnn

<SOAP:Envelope xmlns:SOAP="urn:schemas-xmlsoap-org:soap.v1">

<SOAP:Body>

<m:GetLastTradePriceResponse xmlns:m="Some-Namespace-URI">

</m:GetLastTradePriceResponse>

</SOAP:Body>

</SOAP:Envelope>

other

channel

java

IChannel.java: how the portal calls channel methods

package com.ibs.portal;

import java.util.*;

import javax.servlet.jsp.*;

import javax.servlet.http.*;

public interface IChannel

{

public void initParams (Hashtable params);

public String getName ();

public boolean isMinimizable ();

public boolean isDetachable ();

public boolean isRemovable ();

public boolean isEditable ();

public void render (HttpServletRequest req, HttpServletResponse res, JspWriter out);

public void edit (HttpServletRequest req, HttpServletResponse res, JspWriter out);

}

RSS

Document Type Definition

<!--

Rich Site Summary (RSS) 0.91 official DTD, proposed.

RSS is an XML vocabulary for describing

metadata about websites, and enabling the display of

"channels" on the "My Netscape" website.

RSS Info can be found at http://my.netscape.com/publish/

XML Info can be found at http://www.w3.org/XML/

Dan Libby - danda@netscape.com

Based on RSS DTD originally created by

Lars Marius Garshol - larsga@ifi.uio.no.

$Id: rss-0.91.dtd,v 1.1 1999/07/25 07:59:31 danda Exp $

-->

<!ELEMENT rss (channel)>

<!ATTLIST rss

version CDATA #REQUIRED>

<!ELEMENT title (#PCDATA)>

<!ELEMENT description (#PCDATA)>

<!ELEMENT link (#PCDATA)>

<!ELEMENT url (#PCDATA)>

<!ELEMENT item (title | link | description)*>

<!ELEMENT textinput (title | description | name | link)*>

<!ELEMENT name (#PCDATA)>

<!ELEMENT rating (#PCDATA)>

<!ELEMENT language (#PCDATA)>

<!ELEMENT width (#PCDATA)>

<!ELEMENT height (#PCDATA)>

<!ELEMENT copyright (#PCDATA)>

<!ELEMENT pubDate (#PCDATA)>

<!ELEMENT lastBuildDate (#PCDATA)>

<!ELEMENT docs (#PCDATA)>

<!ELEMENT managingEditor (#PCDATA)>

<!ELEMENT webMaster (#PCDATA)>

<!ELEMENT hour (#PCDATA)>

<!ELEMENT day (#PCDATA)>

<!ELEMENT skipHours (hour+)>

<!ELEMENT skipDays (day+)>

<!--

Copied from HTML 3.2 DTD, with modifications (removed CDATA)

http://www.w3.org/TR/REC-html32.html#dtd

=============== BEGIN ===================

-->

<!--

Character Entities for ISO Latin-1

Permission to copy in any form is granted for use with

conforming SGML systems and applications as defined in

ISO 8879, provided this notice is included in all copies.

This has been extended for use with HTML to cover the full set of codes in the range 160-255 decimal.

-->

<!-- Character entity set. Typical invocation:

<!ENTITY % ISOlat1 PUBLIC

"ISO 8879-1986//ENTITIES Added Latin 1//EN//HTML">

%ISOlat1;

-->

<!ENTITY nbsp " ">

<!ENTITY iexcl "¡">

<!ENTITY cent "¢">

<!ENTITY pound "£">

<!ENTITY curren "¤">

<!ENTITY yen "¥">

<!ENTITY brvbar "¦">

<!ENTITY sect "§">

<!ENTITY uml "¨">

<!ENTITY ordf "ª">

<!ENTITY laquo "«">

<!ENTITY not "¬">

<!ENTITY shy "">

<!ENTITY reg "®">

<!ENTITY macr "¯">

<!ENTITY deg "°">

<!ENTITY plusmn "±">

<!ENTITY sup2 "²">

<!ENTITY sup3 "³">

<!ENTITY acute "´">

<!ENTITY micro "µ">

<!ENTITY para "¶">

<!ENTITY middot "·">

<!ENTITY cedil "¸">

<!ENTITY sup1 "¹">

<!ENTITY ordm "º">

<!ENTITY raquo "»">

<!ENTITY frac14 "¼">

<!ENTITY frac12 "½">

<!ENTITY frac34 "¾">

<!ENTITY iquest "¿">

<!ENTITY Agrave "À">

<!ENTITY Aacute "Á">

<!ENTITY Acirc "Â">

<!ENTITY Atilde "Ã">

<!ENTITY Auml "Ä">

<!ENTITY Aring "Å">

<!ENTITY AElig "Æ">

<!ENTITY Ccedil "Ç">

<!ENTITY Egrave "È">

<!ENTITY Eacute "É">

<!ENTITY Ecirc "Ê">

<!ENTITY Euml "Ë">

<!ENTITY Igrave "Ì">

<!ENTITY Iacute "Í">

<!ENTITY Icirc "Î">

<!ENTITY Iuml "Ï">

<!ENTITY ETH "Ð">

<!ENTITY Ntilde "Ñ">

<!ENTITY Ograve "Ò">

<!ENTITY Oacute "Ó">

<!ENTITY Ocirc "Ô">

<!ENTITY Otilde "Õ">

<!ENTITY Ouml "Ö">

<!ENTITY times "×">

<!ENTITY Oslash "Ø">

<!ENTITY Ugrave "Ù">

<!ENTITY Uacute "Ú">

<!ENTITY Ucirc "Û">

<!ENTITY Uuml "Ü">

<!ENTITY Yacute "Ý">

<!ENTITY THORN "Þ">

<!ENTITY szlig "ß">

<!ENTITY agrave "à">

<!ENTITY aacute "á">

<!ENTITY acirc "â">

<!ENTITY atilde "ã">

<!ENTITY auml "ä">

<!ENTITY aring "å">

<!ENTITY aelig "æ">

<!ENTITY ccedil "ç">

<!ENTITY egrave "è">

<!ENTITY eacute "é">

<!ENTITY ecirc "ê">

<!ENTITY euml "ë">

<!ENTITY igrave "ì">

<!ENTITY iacute "í">

<!ENTITY icirc "î">

<!ENTITY iuml "ï">

<!ENTITY eth "ð">

<!ENTITY ntilde "ñ">

<!ENTITY ograve "ò">

<!ENTITY oacute "ó">

<!ENTITY ocirc "ô">

<!ENTITY otilde "õ">

<!ENTITY ouml "ö">

<!ENTITY divide "÷">

<!ENTITY oslash "ø">

<!ENTITY ugrave "ù">

<!ENTITY uacute "ú">

<!ENTITY ucirc "û">

<!ENTITY uuml "ü">

<!ENTITY yacute "ý">

<!ENTITY thorn "þ">

<!ENTITY yuml "ÿ">

<!--

Copied from HTML 3.2 DTD, with modifications (removed CDATA)

http://www.w3.org/TR/REC-html32.html#dtd

================= END ===================

-->

Sample

<?xml version="1.0"?>

<!DOCTYPE rss PUBLIC "-//Netscape Communications//DTD RSS 0.91//EN" "http://my.netscape.com/publish/formats/rss-0.91.dtd">

<title>StockCharts.com</title>

<description>Free Stock Charts and Expert Market Commentary</description>

<image>

<title>StockCharts.com</title>

<url>http://stockcharts.com/images/sccrss.gif</url>

<description>Free Stock Charts and Expert Market Commentary</description>

</image>

<item>

<title>Mid-Life Growth Investment Strategies - Scott McCormick</title>

<description>Tactical asset management, and the myth of timeliness -- how do these affect the investment strategies you should follow in mid-life? Scott says to pick a triggering event as a review reminder.</description>

</item>

<item>

<title>Promising High-Tech Small Caps - Paulo Prazeres</title>

<description>Everyone is talking about Small Caps, including Paulo. He examines three promising picks -- e.Digital, US Video and iVoice -- and revisits his Dow 12,000 prediction.</description>

</item>

<title>P&F Chart</title>

<description>Enter any US stock, index, or mutual fund symbol:</description>

<name>symbol</name>

</textinput>

</channel>

</rss>

artifacts

administration

Future Directions

Issues

Publishers will need to make arrangements for the resources they will use. Each institution will need to define how they will handle this. for those cases where it makes sense to charge for resources there will be an interface that allows the billing component to see when resources are allocated and freed.

Revision History