Content Repository

ACS Content Design Document

I. Essentials

Requirements

II. Introduction

The ACS Content package allows different applications to store content in the centralized location of a single table. This content could be ordinary data or data representations of objects. In the content repository, any object is associated with single piece of content. The content is represented by a BLOB, a binary large object. Such content could be text, an image, a video, or binary information of any sort.

III. Historical Consideration

The development of the content repository was originally motivated by a need for site wide search support. The site wide search needed a centralized facility to search all objects' content.

IV. Competitive Analysis

to be filled in

V. Design Tradeoffs

Currently there is a content repository system, or CR, provided with the ACS Development platform. It has a lot of useful features, such as support for revisions, containers, and search capabilities, and is great for most publishing tasks. Unfortunately, it has a lot of overhead for certain applications that do not require such capabilities. For example, a phone book application would only need the search capability. In order to use the search capability, the phone book application would have to build on top of the current CR architecture.

The goal of the design of the ACS Content system is to simplify the content repository to support centralized storage for all applications. The simplified CR will only contain the basic attributes of a content, namely format and language. Format and language are needed to support manipulation and display of the content. ACS Content will not be an object since it does not require any use of permissioning or the ACS relational object oriented architecture. [need to flesh this out more explicitly; what does it mean to say that a package isn't an object?] It is merely a storage facility.

VI. API

There are functions available for creating and deleting objects and their content association. They are defined within the acs_content package.

 function new (
 object_id in acs_objects.object_id%TYPE null,
 mime_type in acs_contents.mime_type%TYPE null,
 nls_language in acs_contents.nls_lanaguage%TYPE
 ...
 ) return acs_objects.object_id%TYPE;
 procedure delete (
 object_id in acs_objects.object_id%TYPE
 );

VII. Data Model Discussion

There is one table for the simplified content repository. The acs_content table stores the association between object and content:

create table acs_contents (
 content_id integer
 constraint acs_cont_obj_id_fk references acs_objects(object_id)
 constraint acs_cont_rep_obj_id_pk primary key,
 content blob,
 searchable_p char(1) default 't'
 constraint acs_cont_rep_searchable_p_ck check (searchable_p in ('t','f'))
 constraint acs_cont_rep_searchable_p_nn not null,
 -- stores the language of the content
 nls_language varchar2(50),
 -- mime type
 mime_type varchar2(200) default 'text/plain'
);

The searchable_p indicates the searchable attribute of the content. It allows applications to determine whether the content is ready to searched.

VIII. User Interface

to be filled in

IX. Configuration/Parameters

to be filled in

X. Future Improvements/Areas of Likely Change

A much more stable applet based client interface would be in order. It would also be nice if we allowed more concurrent applet connections to the server.

XI. Authors

System creator: Khy Huang
System owner: Khy Huang
Documentation authors: Khy Huang

VII. Revision History

Document Revision #	Action Taken, Notes	When?	By Whom?
0.4	More editing	2000-12-15	Josh Finkler
0.3	Edited	2000-11-27	Khy Huang
0.2	Edited	2000-11-20	Josh Finkler and Khy Huang
0.2	Edited	2000-11-20	John Prevost
0.1	Created	2000-11-17