Index: openacs-4/packages/acs-core-docs/www/object-system-requirements.html
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/object-system-requirements.html,v
diff -u -r1.6 -r1.6.2.1
--- openacs-4/packages/acs-core-docs/www/object-system-requirements.html	10 Aug 2002 20:07:20 -0000	1.6
+++ openacs-4/packages/acs-core-docs/www/object-system-requirements.html	24 Nov 2002 21:29:17 -0000	1.6.2.1
@@ -1,9 +1,9 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-<html><head><meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"><title>OpenACS 4 Object Model Requirements</title><meta name="generator" content="DocBook XSL Stylesheets V1.50.0"><link rel="home" href="index.html" title="OpenACS Documentation"><link rel="up" href="kernel-doc.html" title="Chapter 7. Kernel Documentation"><link rel="previous" href="kernel-overview.html" title="Overview"><link rel="next" href="object-system-design.html" title="OpenACS 4 Object Model Design"><link rel="stylesheet" href="openacs.css" type="text/css"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><a href="http://openacs.org"><img src="images/alex.jpg" border="0"></a><table width="100%" summary="Navigation header" border="0"><tr><td width="20%" align="left"><a accesskey="p" href="kernel-overview.html">Prev</a>&nbsp;</td><th width="60%" align="center">Chapter 7. Kernel Documentation</th><td width="20%" align="right">&nbsp;<a accesskey="n" href="object-system-design.html">Next</a></td></tr></table><hr></div><div class="sect1"><div class="titlepage"><div><h2 class="title" style="clear: both"><a name="object-system-requirements"></a>OpenACS 4 Object Model Requirements</h2></div></div><div class="authorblurb"><p>
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>OpenACS 4 Object Model Requirements</title><meta name="generator" content="DocBook XSL Stylesheets V1.56.1"><link rel="home" href="index.html" title="OpenACS Documentation"><link rel="up" href="kernel-doc.html" title="Chapter�7.�Kernel Documentation"><link rel="previous" href="kernel-overview.html" title="Overview"><link rel="next" href="object-system-design.html" title="OpenACS 4 Object Model Design"><link rel="stylesheet" href="openacs.css" type="text/css"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><a href="http://openacs.org"><img src="images/alex.jpg" border="0"></a><table width="100%" summary="Navigation header" border="0"><tr><td width="20%" align="left"><a accesskey="p" href="kernel-overview.html">Prev</a>&nbsp;</td><th width="60%" align="center">Chapter�7.�Kernel Documentation</th><td width="20%" align="right">&nbsp;<a accesskey="n" href="object-system-design.html">Next</a></td></tr></table><hr></div><div class="sect1"><div class="titlepage"><div><h2 class="title" style="clear: both"><a name="object-system-requirements"></a>OpenACS 4 Object Model Requirements</h2></div></div><div class="authorblurb"><p>
 By <a href="mailto:psu@arsdigita.com" target="_top">Pete Su</a><br>
-		  OpenACS docs are written by the named authors, but may be edited
-		  by OpenACS documentation staff.
-		</p></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="object-system-requirements-"></a>I. Introduction</h3></div></div><p>A major goal in OpenACS 4 is to unify and normalize many of the core services
+          OpenACS docs are written by the named authors, but may be edited
+          by OpenACS documentation staff.
+        </p></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="object-system-requirements-"></a>I. Introduction</h3></div></div><p>A major goal in OpenACS 4 is to unify and normalize many of the core services
 of the system into a coherent common data model and API. In the past, these
 services were provided to applications in an ad-hoc and irregular fashion.
 Examples of such services include:</p><div class="itemizedlist"><ul type="disc"><li><p>General Comments</p></li><li><p>User/groups</p></li><li><p>Attribute storage in user/groups</p></li><li><p>General Permissions</p></li><li><p>Site wide search</p></li><li><p>General Auditing</p></li></ul></div><p>All of these services involve relating extra information and services to
@@ -24,7 +24,7 @@
 within the OpenACS, and typically corresponds to a single row within the
 relational database.</p></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="object-system-requirements-vision"></a>Vision Statement</h3></div></div><p>The OpenACS 4 Object Model must address five high-level requirements that
 repeatedly exhibit themselves in the context of existing services in OpenACS 3.x,
-as described below.</p><p><span class="strong"><em>Object Identifiers for General Services</em></span></p><p>Generic services require a single unambiguous way of identifying
+as described below.</p><p><span class="strong">Object Identifiers for General Services</span></p><p>Generic services require a single unambiguous way of identifying
 application objects that they manage or manipulate. In OpenACS 3.x, there are
 several different idioms that construct object identifiers from other data.
 Many modules use a <tt>(user_id, group_id, scope)</tt> triple combination
@@ -46,12 +46,12 @@
 that their definition and use is ad-hoc and inconsistent. This makes the
 construction of generic application-independent services difficult.
 Therefore, the OpenACS 4 Object Model should provide a centralized and uniform
-mechanism for tagging application objects with unique identifiers.</p><p><span class="strong"><em>Support for Unified Access Control</em></span></p><p>Access control should be as transparent as possible to the application
+mechanism for tagging application objects with unique identifiers.</p><p><span class="strong">Support for Unified Access Control</span></p><p>Access control should be as transparent as possible to the application
 developer. Until the implementation of the general permissions system, every
 OpenACS application had to manage access control to its data separately. Later
 on, a notion of &quot;scoping&quot; was introduced into the core data
 model.</p><p>&quot;Scope&quot; is a term best explained by example. Consider some
-hypothetical rows in the <tt>address_book</tt> table:</p><blockquote class="blockquote"><div class="informaltable"><table border="1"><colgroup><col><col><col><col></colgroup><tbody><tr><td><span class="strong"><em>...</em></span></td><td><span class="strong"><em><tt>scope</tt></em></span></td><td><span class="strong"><em><tt>user_id</tt></em></span></td><td><span class="strong"><em><tt>group_id</tt></em></span></td><td><span class="strong"><em>...</em></span></td></tr><tr><td>...</td><td><tt>user</tt></td><td><tt>123</tt></td><td>�</td><td>...</td></tr><tr><td>...</td><td><tt>group</tt></td><td>�</td><td><tt>456</tt></td><td>...</td></tr><tr><td>...</td><td><tt>public</tt></td><td>�</td><td>�</td><td>...</td></tr></tbody></table></div></blockquote><p>The first row represents an entry in User 123's personal address book,
+hypothetical rows in the <tt>address_book</tt> table:</p><blockquote class="blockquote"><div class="informaltable"><table border="1"><colgroup><col><col><col><col></colgroup><tbody><tr><td><span class="strong">...</span></td><td><span class="strong"><tt>scope</tt></span></td><td><span class="strong"><tt>user_id</tt></span></td><td><span class="strong"><tt>group_id</tt></span></td><td><span class="strong">...</span></td></tr><tr><td>...</td><td><tt>user</tt></td><td><tt>123</tt></td><td>�</td><td>...</td></tr><tr><td>...</td><td><tt>group</tt></td><td>�</td><td><tt>456</tt></td><td>...</td></tr><tr><td>...</td><td><tt>public</tt></td><td>�</td><td>�</td><td>...</td></tr></tbody></table></div></blockquote><p>The first row represents an entry in User 123's personal address book,
 the second row represents an entry in User Group 456's shared address
 book, and the third row represents an entry in the site's public address
 book.</p><p>In this way, the scoping columns identify the security context in which a
@@ -65,7 +65,7 @@
 page, a security problem could result.</p><p>Thus the OpenACS 4 Object Model must support a more general access control
 system that allows access control domains to be hierarchical, and specifiable
 with a single piece of data, instead of the old composite keys described
-above.</p><p><span class="strong"><em>Extensible Data Models</em></span></p><p>Another problem with previous OpenACS data models is that many of the central
+above.</p><p><span class="strong">Extensible Data Models</span></p><p>Another problem with previous OpenACS data models is that many of the central
 tables in the system became bloated as they were extended to support an
 increasing number of modules. The <tt>users</tt> table is the best case
 in point: it became full of columns that exist for various special
@@ -83,10 +83,10 @@
 custom extensions to the existing data models, and the OM does the
 bookkeeping necessary to make this easier, providing a generic API for object
 creation that automatically keeps track of the location and relationships
-between data.</p><p><span class="strong"><em>Design Note:</em></span> While this doesn't really belong in a
+between data.</p><p><span class="strong">Design Note:</span> While this doesn't really belong in a
 requirements document, the fact that we are constrained to using relational
 databases means that certain constraints on the overall design of the object
-data model exist, which you can read about in <a href="object-system-design.html#object-system-design-summary">Summary and Design Considerations</a>.</p><p><span class="strong"><em>Modifiable Data Models</em></span></p><p>Another recurring applications problem is how to store a modifiable data
+data model exist, which you can read about in <a href="object-system-design.html#object-system-design-summary">Summary and Design Considerations</a>.</p><p><span class="strong">Modifiable Data Models</span></p><p>Another recurring applications problem is how to store a modifiable data
 model, or how to store information that may change extensively between
 releases or in different client installations. Furthermore, we want to avoid
 changes to an application's database queries in the face of any custom
@@ -103,7 +103,7 @@
 store values for those attributes.</p></li></ul></div><p>Thus the Object Model must provide a general mechanism for applications
 and developers to modify or extend data models, without requiring changes to
 the SQL schema of the system. This ensures that all applications use the same
-base schema, resulting in a uniform and more maintainable system.</p><p><span class="strong"><em>Generic Relations</em></span></p><p>Many OpenACS applications define simple relationships between application
+base schema, resulting in a uniform and more maintainable system.</p><p><span class="strong">Generic Relations</span></p><p>Many OpenACS applications define simple relationships between application
 objects, and tag those relationships with extra data. In OpenACS 3.x, this was
 done using <span class="emphasis"><em>mapping tables</em></span>. The user/groups module has the most
 highly developed data model for this purpose, using a single table called
@@ -127,8 +127,8 @@
 that store metadata on application objects. The object type system supports
 subtyping with inheritance, so new object types can be defined in terms of
 existing object types.</p><p>The OM data model forms the main part of the OpenACS 4 Kernel data model. The
-other parts of the Kernel data model include:</p><div class="itemizedlist"><ul type="disc"><li><p>Parties and Groups</p></li><li><p>Permissions</p></li></ul></div><p>Each of these is documented elsewhere at length.</p></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="object-system-requirements-use-cases"></a>Use-cases and User-scenarios</h3></div></div><p>(Pending as of 8/27/00)</p></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="object-system-requirements-links"></a>Related Links</h3></div></div><div class="itemizedlist"><ul type="disc"><li><p><a href="object-system-design.html">OpenACS 4 Object Model Design</a></p></li><li><p><a href="objects.html">OpenACS 4.5 Data Models and the Object System</a></p></li></ul></div></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="object-system-requirements-data-model"></a>Requirements: Data Model</h3></div></div><p>The data model for the object system provides support for the following
-kinds of schema patterns that are used by many existing OpenACS modules:</p><div class="variablelist"><dl><dt><span class="term"><span class="strong"><em>10.0 Object Identification and Storage</em></span></span></dt><dd><p>Object identification is a central mechanism in the new metadata system.
+other parts of the Kernel data model include:</p><div class="itemizedlist"><ul type="disc"><li><p>Parties and Groups</p></li><li><p>Permissions</p></li></ul></div><p>Each of these is documented elsewhere at length.</p></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="object-system-requirements-use-cases"></a>Use-cases and User-scenarios</h3></div></div><p>(Pending as of 8/27/00)</p></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="object-system-requirements-links"></a>Related Links</h3></div></div><div class="itemizedlist"><ul type="disc"><li><p><a href="object-system-design.html">OpenACS 4 Object Model Design</a></p></li><li><p><a href="objects.html">OpenACS 4.6 Data Models and the Object System</a></p></li></ul></div></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="object-system-requirements-data-model"></a>Requirements: Data Model</h3></div></div><p>The data model for the object system provides support for the following
+kinds of schema patterns that are used by many existing OpenACS modules:</p><div class="variablelist"><dl><dt><span class="term"><span class="strong">10.0 Object Identification and Storage</span></span></dt><dd><p>Object identification is a central mechanism in the new metadata system.
 The fact that every object has a known unique identifier means that the core
 can deal with all objects in a generic way. Thus the only action required of
 an application to obtain any general service is to &quot;hook into&quot; the
@@ -149,15 +149,15 @@
 application data. More importantly, object identifiers will enable developers
 to readily build and use generic services that work globally across a
 system.</p><p>The object identifiers should be subject to the following
-requirements:</p><p><span class="strong"><em>10.10 Uniqueness</em></span></p><p>The object ID should be unique among all the IDs in the entire OpenACS system
-in which the object lives.</p><p><span class="strong"><em>10.20 Useful as a Reference</em></span></p><p>Applications should be able to use the unique object ID as a reference,
-with which they can fetch any or all of the object's attributes.</p><p><span class="strong"><em>10.30 Storable</em></span></p><p>Object IDs should be storable in tables. e.g. you should be able to use
+requirements:</p><p><span class="strong">10.10 Uniqueness</span></p><p>The object ID should be unique among all the IDs in the entire OpenACS system
+in which the object lives.</p><p><span class="strong">10.20 Useful as a Reference</span></p><p>Applications should be able to use the unique object ID as a reference,
+with which they can fetch any or all of the object's attributes.</p><p><span class="strong">10.30 Storable</span></p><p>Object IDs should be storable in tables. e.g. you should be able to use
 them to implement mapping tables between objects, to represent
-relationships.</p><p><span class="strong"><em>10.40 Moveable</em></span></p><p>Objects should be mobile between databases. That is, information will
+relationships.</p><p><span class="strong">10.40 Moveable</span></p><p>Objects should be mobile between databases. That is, information will
 often need to be moved between multiple servers (development, staging, and
 production), so a mechanism for moving this data is necessary. In addition, a
 mechanism for tagging these objects in a way similar to CVS would be useful
-in determining which objects need to be synchronized.</p></dd><dt><span class="term"><span class="strong"><em>20.0 Object Types</em></span></span></dt><dd><p>An <span class="emphasis"><em>object type</em></span> refers to a specification of one or more
+in determining which objects need to be synchronized.</p></dd><dt><span class="term"><span class="strong">20.0 Object Types</span></span></dt><dd><p>An <span class="emphasis"><em>object type</em></span> refers to a specification of one or more
 attributes to be managed along with a piece of application data.</p><p>The object system should provide a data model for describing and
 representing object types. This data model is somewhat analogous to the
 Oracle data dictionary, which stores information about all user defined
@@ -170,33 +170,33 @@
 is meant to be a generalization of this mechanism. The data model should
 allow developers to at least do everything they used to with user/groups, but
 without its administrative hassles.</p><p>Therefore, the data model must be able to represent object types that have
-the following characteristics:</p><p><span class="strong"><em>20.10 Type Name</em></span></p><p>A human readable name for the object type.</p><p><span class="strong"><em>20.20 Type Attributes</em></span></p><p>Attributes whose values are shared by all instances of the object
-type.</p><p><span class="strong"><em>20.30 Object Attributes</em></span></p><p>Attributes that are specific to each particular object belonging to a
-given type.</p><p>The data model must also enforce certain constraints on object types:</p><p><span class="strong"><em>20.40 Type Uniqueness</em></span></p><p>Object type names must be unique.</p><p><span class="strong"><em>20.50 Attribute Name Uniqueness</em></span></p><p>Attribute names must be unique in the scope of a single object type and
-any of its parent types.</p></dd><dt><span class="term"><span class="strong"><em>30.0 Type Extension</em></span></span></dt><dd><p>The Object Model must support the definition of object types that are
+the following characteristics:</p><p><span class="strong">20.10 Type Name</span></p><p>A human readable name for the object type.</p><p><span class="strong">20.20 Type Attributes</span></p><p>Attributes whose values are shared by all instances of the object
+type.</p><p><span class="strong">20.30 Object Attributes</span></p><p>Attributes that are specific to each particular object belonging to a
+given type.</p><p>The data model must also enforce certain constraints on object types:</p><p><span class="strong">20.40 Type Uniqueness</span></p><p>Object type names must be unique.</p><p><span class="strong">20.50 Attribute Name Uniqueness</span></p><p>Attribute names must be unique in the scope of a single object type and
+any of its parent types.</p></dd><dt><span class="term"><span class="strong">30.0 Type Extension</span></span></dt><dd><p>The Object Model must support the definition of object types that are
 subtypes of existing types. A subtype inherits all the attributes of its
 parent type, and defines some attributes of its own. A critical aspect of the
 OM is parent types may be altered, and any such change must propagate to
 child subtypes.</p><p>The OM data model must enforce constraints on subtypes that are similar to
-the ones on general object types.</p><p><span class="strong"><em>30.10 Subtype Uniqueness</em></span></p><p>Subtype names must be unique (this parallels requirement 10.40).</p><p><span class="strong"><em>30.20 Subtype Attribute Name Uniqueness</em></span></p><p>Attribute names must be unique in the scope of a single object
-subtype.</p><p><span class="strong"><em>30.30 Parent Type Prerequisite</em></span></p><p>Subtypes must be defined in terms of parent types that, in fact, already
-exist.</p><p><span class="strong"><em>30.40</em></span></p><p>The extended attribute names in a subtype must not be the same as those in
-its parent type.</p></dd><dt><span class="term"><span class="strong"><em>35.0 Methods</em></span></span></dt><dd><p><span class="strong"><em>35.10 Method and Type Association</em></span></p><p>The OM data model should define a mechanism for associating procedural
+the ones on general object types.</p><p><span class="strong">30.10 Subtype Uniqueness</span></p><p>Subtype names must be unique (this parallels requirement 10.40).</p><p><span class="strong">30.20 Subtype Attribute Name Uniqueness</span></p><p>Attribute names must be unique in the scope of a single object
+subtype.</p><p><span class="strong">30.30 Parent Type Prerequisite</span></p><p>Subtypes must be defined in terms of parent types that, in fact, already
+exist.</p><p><span class="strong">30.40</span></p><p>The extended attribute names in a subtype must not be the same as those in
+its parent type.</p></dd><dt><span class="term"><span class="strong">35.0 Methods</span></span></dt><dd><p><span class="strong">35.10 Method and Type Association</span></p><p>The OM data model should define a mechanism for associating procedural
 code, called <span class="emphasis"><em>methods</em></span>, with objects of a given type. Methods are
 associated with the each object <span class="emphasis"><em>type</em></span> - not each object
-<span class="emphasis"><em>instance</em></span>.</p><p><span class="strong"><em>35.20 Method Sharing</em></span></p><p>All instances of a given object type should share the same set of defined
-methods for that type.</p></dd><dt><span class="term"><span class="strong"><em>40.0 Object Attribute Value Storage</em></span></span></dt><dd><p>In addition to information on types, the OM data model provides for the
+<span class="emphasis"><em>instance</em></span>.</p><p><span class="strong">35.20 Method Sharing</span></p><p>All instances of a given object type should share the same set of defined
+methods for that type.</p></dd><dt><span class="term"><span class="strong">40.0 Object Attribute Value Storage</span></span></dt><dd><p>In addition to information on types, the OM data model provides for the
 centralized storage of object attribute values. This facility unifies the
 many ad-hoc attribute/value tables that exist in various OpenACS 3.x data models,
 such as:</p><div class="itemizedlist"><ul type="disc"><li><p>User groups: Each instance of a group type can have custom data.</p></li><li><p>Photo DB: Users can define their own custom metadata to attach to
 photograph objects.</p></li><li><p>Ecommerce: Vendors can attach custom fields to the data model describing
-their products.</p></li></ul></div><p><span class="strong"><em>40.10 Generic Retrieval</em></span></p><p>Attributes should be stored so that they are retrievable in a way that is
+their products.</p></li></ul></div><p><span class="strong">40.10 Generic Retrieval</span></p><p>Attributes should be stored so that they are retrievable in a way that is
 independent of the type of the object that they belong to. That is, the only
 data needed to retrieve an attribute should be the system-wide ID of an
-object (see requirement 10.20 above) and the attribute name.</p><p><span class="strong"><em>40.20 Inherited Attributes</em></span></p><p>The system should allow for the automatic retrieval of inherited attribute
-values, for an object belonging to a subtype.</p><p><span class="strong"><em>40.30. Constraints on Attributes</em></span></p><p>The system should allow the developer to put down constraints on the
+object (see requirement 10.20 above) and the attribute name.</p><p><span class="strong">40.20 Inherited Attributes</span></p><p>The system should allow for the automatic retrieval of inherited attribute
+values, for an object belonging to a subtype.</p><p><span class="strong">40.30. Constraints on Attributes</span></p><p>The system should allow the developer to put down constraints on the
 values that an attribute may hold, for the purposes of maintaining
-application specific integrity rules.</p></dd><dt><span class="term"><span class="strong"><em>50.0 Object Contexts</em></span></span></dt><dd><p>In OpenACS 3.x, there was a notion of &quot;scope&quot; for application
+application specific integrity rules.</p></dd><dt><span class="term"><span class="strong">50.0 Object Contexts</span></span></dt><dd><p>In OpenACS 3.x, there was a notion of &quot;scope&quot; for application
 objects. An object could be belong to one of three scopes: public, group or
 user. This provided a crude way to associate objects with particular scopes
 in the system, but it was awkward to use and limited in flexibility.</p><p>The OpenACS 4 Object Model provides a generalized notion of scope that allows
@@ -205,66 +205,64 @@
 object has no explicit permissions attached to it, then it inherits
 permissions from its context.</p><p>The context data model also forms the basis of the <a href="subsites-requirements.html" title="OpenACS 4 Subsites Requirements">subsites system</a>, and is
 a basic part of the <a href="permissions-requirements.html" title="OpenACS 4 Permissions Requirements">permissions system</a>,
-described in separate documents.</p><p>The context data model should provide the following facilities:</p><p><span class="strong"><em>50.10 Unique ID</em></span></p><p>Every context should have a unique ID in the system.</p><p><span class="strong"><em>50.20 Tree Structure</em></span></p><p>The data model should support a tree structured organization of contexts.
+described in separate documents.</p><p>The context data model should provide the following facilities:</p><p><span class="strong">50.10 Unique ID</span></p><p>Every context should have a unique ID in the system.</p><p><span class="strong">50.20 Tree Structure</span></p><p>The data model should support a tree structured organization of contexts.
 That is, contexts can be logically &quot;contained&quot; within other
 contexts (i.e. contexts have parents) and contexts can contain other contexts
-(i.e. contexts can have children).</p><p><span class="strong"><em>50.30 Data Model Constraints</em></span></p><p>All objects must have a context ID. This ID must refer to an existing
+(i.e. contexts can have children).</p><p><span class="strong">50.30 Data Model Constraints</span></p><p>All objects must have a context ID. This ID must refer to an existing
 context or be NULL. The meaning of a NULL context is determined by the
-implementation.</p><p><span class="strong"><em>Note:</em></span></p><p>The current system interprets the NULL context as meaning the default
+implementation.</p><p><span class="strong">Note:</span></p><p>The current system interprets the NULL context as meaning the default
 &quot;site-wide&quot; context in some sense. I wanted to note this fact for
 others, but there is no need to make this a requirement of the system. I
 think it would be reasonable to have a NULL context be an error (psu
-8/24/2000).</p></dd><dt><span class="term"><span class="strong"><em>55.0 Object Relations</em></span></span></dt><dd><p>The data model should include a notion of pair-wise relations between
+8/24/2000).</p></dd><dt><span class="term"><span class="strong">55.0 Object Relations</span></span></dt><dd><p>The data model should include a notion of pair-wise relations between
 objects. Relations should be able to record simple facts of the form
 &quot;object X is related to object Y by relationship R,&quot; and also be
-able to attach attributes to these facts.</p></dd></dl></div></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="object-system-requirements-api"></a>Requirements: API</h3></div></div><p>The API should let programmers accomplish the following actions:</p><div class="variablelist"><dl><dt><span class="term"><span class="strong"><em>60.0 Object Type Creation</em></span></span></dt><dd><p><span class="strong"><em>60.10 Create a New Object Type</em></span></p><p>The object system API should provide a procedure call that creates a new
+able to attach attributes to these facts.</p></dd></dl></div></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="object-system-requirements-api"></a>Requirements: API</h3></div></div><p>The API should let programmers accomplish the following actions:</p><div class="variablelist"><dl><dt><span class="term"><span class="strong">60.0 Object Type Creation</span></span></dt><dd><p><span class="strong">60.10 Create a New Object Type</span></p><p>The object system API should provide a procedure call that creates a new
 object type by running the appropriate transactions on the object system data
 model. This API call is subject to the constraints laid out in the data
-model. We call this operation &quot;instantiating&quot; an object.</p><p><span class="strong"><em>60.20 Create a New Object Subtype</em></span></p><p>The object system API should provide a procedure call for creating
+model. We call this operation &quot;instantiating&quot; an object.</p><p><span class="strong">60.20 Create a New Object Subtype</span></p><p>The object system API should provide a procedure call for creating
 subtypes of a given type. Operationally, this API is the same as requirement
 60.10. Instances of subtypes automatically contain all attributes of the
 parent type in addition to all attributes of the subtype. This API is subject
-to the constraints laid out in the data model.</p><p><span class="strong"><em>60.30 Create a New Relation Type</em></span></p><p>There should be an API call to create a new type of object relation.
+to the constraints laid out in the data model.</p><p><span class="strong">60.30 Create a New Relation Type</span></p><p>There should be an API call to create a new type of object relation.
 Relation types can be modeled as object types. The API below for manipulating
-attributes can then be used to add attributes to relation types.</p></dd><dt><span class="term"><span class="strong"><em>70.0 Update an Object Type</em></span></span></dt><dd><p>The object system API must allow the programmer to modify, add, and delete
+attributes can then be used to add attributes to relation types.</p></dd><dt><span class="term"><span class="strong">70.0 Update an Object Type</span></span></dt><dd><p>The object system API must allow the programmer to modify, add, and delete
 attributes from any object type. Updates should be propagated to any child
 subtypes. This API is subject to the constraints laid out in the data
-model.</p></dd><dt><span class="term"><span class="strong"><em>80.0 Delete an Object Type</em></span></span></dt><dd><p>The system provides an API call for deleting an object type.</p><p><span class="strong"><em>80.10</em></span></p><p>Deleting an object type destroys all instances of the type. It should be
+model.</p></dd><dt><span class="term"><span class="strong">80.0 Delete an Object Type</span></span></dt><dd><p>The system provides an API call for deleting an object type.</p><p><span class="strong">80.10</span></p><p>Deleting an object type destroys all instances of the type. It should be
 an error to delete types that have dependent subtypes. This API is subject to
-the constraints laid out in the data model.</p><p><span class="strong"><em>80.10.10</em></span></p><p>However, the programmer should also be able to specify that all the
+the constraints laid out in the data model.</p><p><span class="strong">80.10.10</span></p><p>However, the programmer should also be able to specify that all the
 subtypes and instances of those subtypes be destroyed before destroying the
 object type. This is similar to a &quot;delete cascade&quot; constraint in
-SQL.</p></dd><dt><span class="term"><span class="strong"><em>90.0 Object Instance Creation and Destruction</em></span></span></dt><dd><p>The system must provide API calls to manage the creation and destruction
-of object instances.</p><p><span class="strong"><em>90.10 Create an Instance of an Object Type</em></span></p><p>The system should provide an API call for creating a new instance of a
+SQL.</p></dd><dt><span class="term"><span class="strong">90.0 Object Instance Creation and Destruction</span></span></dt><dd><p>The system must provide API calls to manage the creation and destruction
+of object instances.</p><p><span class="strong">90.10 Create an Instance of an Object Type</span></p><p>The system should provide an API call for creating a new instance of a
 given object type. The new instance should be populated with values for each
 of the attributes specified in the definition of the type. In addition, it
 should be possible to create the new instance with an optional context ID
-that refers to the default context that the object will live in.</p><p><span class="strong"><em>90.20 Delete an Object Instance</em></span></p><p>The OM should provide an API call for object deletion. Objects can be
+that refers to the default context that the object will live in.</p><p><span class="strong">90.20 Delete an Object Instance</span></p><p>The OM should provide an API call for object deletion. Objects can be
 deleted only when no other objects in the system refer to them. Since it
 might not be practical to provide a mechanism like &quot;delete cascade&quot;
 here in a reliable way, providing such a facility in the system is
-optional.</p></dd><dt><span class="term"><span class="strong"><em>94.0 Object Relation Creation and Destruction</em></span></span></dt><dd><p>The system must provide API calls to manage the creation and destruction
-of object relations.</p></dd><dt><span class="term"><span class="strong"><em>94.10 Create an Object Relation</em></span></span></dt><dd><p>The OM must provide an API call to declare that two objects are related to
+optional.</p></dd><dt><span class="term"><span class="strong">94.0 Object Relation Creation and Destruction</span></span></dt><dd><p>The system must provide API calls to manage the creation and destruction
+of object relations.</p></dd><dt><span class="term"><span class="strong">94.10 Create an Object Relation</span></span></dt><dd><p>The OM must provide an API call to declare that two objects are related to
 each other by a given relation type. This API call should also allow
-programmers to attach attributes to this object relation.</p></dd><dt><span class="term"><span class="strong"><em>94.20 Destroy an Object Relation</em></span></span></dt><dd><p>There should be an API call for destroying object relations and their
-attributes.</p></dd><dt><span class="term"><span class="strong"><em>95.10 Create and Destroy Contexts</em></span></span></dt><dd><p>The system should provide an API to create and destroy object
-contexts.</p></dd><dt><span class="term"><span class="strong"><em>100.10 Set Attribute Values for an Object</em></span></span></dt><dd><p>The system should provide an API for updating the attribute values of a
-particular instance of an object type.</p></dd><dt><span class="term"><span class="strong"><em>110.10 Get Attribute Values for an Object</em></span></span></dt><dd><p>The system should provide an API for retrieving attribute values from a
-particular instance of an object type.</p></dd><dt><span class="term"><span class="strong"><em>120.10 Efficiency</em></span></span></dt><dd><p>The Object Model must support the efficient storage and retrieval of
+programmers to attach attributes to this object relation.</p></dd><dt><span class="term"><span class="strong">94.20 Destroy an Object Relation</span></span></dt><dd><p>There should be an API call for destroying object relations and their
+attributes.</p></dd><dt><span class="term"><span class="strong">95.10 Create and Destroy Contexts</span></span></dt><dd><p>The system should provide an API to create and destroy object
+contexts.</p></dd><dt><span class="term"><span class="strong">100.10 Set Attribute Values for an Object</span></span></dt><dd><p>The system should provide an API for updating the attribute values of a
+particular instance of an object type.</p></dd><dt><span class="term"><span class="strong">110.10 Get Attribute Values for an Object</span></span></dt><dd><p>The system should provide an API for retrieving attribute values from a
+particular instance of an object type.</p></dd><dt><span class="term"><span class="strong">120.10 Efficiency</span></span></dt><dd><p>The Object Model must support the efficient storage and retrieval of
 object attributes. Since the OM is intended to form the core of many general
 services in the OpenACS, and these services will likely make extensive use of the
 OM tables, queries on these tables must be fast. The major problem here seems
 to be supporting subtyping and inheritance in a way that does not severely
-impact query performance.</p></dd><dt><span class="term"><span class="strong"><em>130.10 Ease of Use</em></span></span></dt><dd><p>Most OpenACS packages will be expected to use the Object Model in one way or
+impact query performance.</p></dd><dt><span class="term"><span class="strong">130.10 Ease of Use</span></span></dt><dd><p>Most OpenACS packages will be expected to use the Object Model in one way or
 another. Since it is important that the largest audience of developers
 possible adopts and uses the OM, it must be easy to incorporate into
 applications, and it must not impose undue requirements on an
 application's data model. In other words, it should be easy to &quot;hook
 into&quot; the object model, and that ability should not have a major impact
-on the application data model.</p><p><span class="strong"><em>Note:</em></span> Is the API the only way to obtain values? How does
-this integrate with application level SQL queries?</p></dd></dl></div></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="object-system-requirements-history"></a>Revision History</h3></div></div><div class="informaltable"><table border="1"><colgroup><col><col><col><col></colgroup><tbody><tr><td><span class="strong"><em>Document Revision #</em></span></td><td><span class="strong"><em>Action Taken, Notes</em></span></td><td><span class="strong"><em>When?</em></span></td><td><span class="strong"><em>By Whom?</em></span></td></tr><tr><td>0.1</td><td>Creation</td><td>08/10/2000</td><td>Bryan Quinn</td></tr><tr><td>0.2</td><td>Major re-write</td><td>08/11/2000</td><td>Pete Su</td></tr><tr><td>0.3</td><td>Draft completed after initial reviews</td><td>08/22/2000</td><td>Pete Su</td></tr><tr><td>0.4</td><td>Edited, updated to conform to requirements template, pending freeze</td><td>08/23/2000</td><td>Kai Wu</td></tr><tr><td>�</td><td>Final edits before freeze</td><td>08/24/2000</td><td>Pete Su</td></tr><tr><td>0.5</td><td>Edited for consistency</td><td>08/27/2000</td><td>Kai Wu</td></tr><tr><td>0.6</td><td>Put Object ID stuff first, because it makes more sense</td><td>08/28/2000</td><td>Pete Su</td></tr><tr><td>0.7</td><td>Added requirement that knowledge-level objects must be moveable between
+on the application data model.</p><p><span class="strong">Note:</span> Is the API the only way to obtain values? How does
+this integrate with application level SQL queries?</p></dd></dl></div></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="object-system-requirements-history"></a>Revision History</h3></div></div><div class="informaltable"><table border="1"><colgroup><col><col><col><col></colgroup><tbody><tr><td><span class="strong">Document Revision #</span></td><td><span class="strong">Action Taken, Notes</span></td><td><span class="strong">When?</span></td><td><span class="strong">By Whom?</span></td></tr><tr><td>0.1</td><td>Creation</td><td>08/10/2000</td><td>Bryan Quinn</td></tr><tr><td>0.2</td><td>Major re-write</td><td>08/11/2000</td><td>Pete Su</td></tr><tr><td>0.3</td><td>Draft completed after initial reviews</td><td>08/22/2000</td><td>Pete Su</td></tr><tr><td>0.4</td><td>Edited, updated to conform to requirements template, pending freeze</td><td>08/23/2000</td><td>Kai Wu</td></tr><tr><td>�</td><td>Final edits before freeze</td><td>08/24/2000</td><td>Pete Su</td></tr><tr><td>0.5</td><td>Edited for consistency</td><td>08/27/2000</td><td>Kai Wu</td></tr><tr><td>0.6</td><td>Put Object ID stuff first, because it makes more sense</td><td>08/28/2000</td><td>Pete Su</td></tr><tr><td>0.7</td><td>Added requirement that knowledge-level objects must be moveable between
 databases.</td><td>08/29/2000</td><td>Richard Li</td></tr><tr><td>0.8</td><td>Rewrote intro to match language and concepts in the design document. Also
 cleaned up usage a bit in the requirements section. Added short vague
-requirements on relation types.</td><td>09/06/2000</td><td>Pete Su</td></tr><tr><td>0.9</td><td>Edited for ACS 4 Beta release.</td><td>09/30/2000</td><td>Kai Wu</td></tr></tbody></table></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="kernel-overview.html">Prev</a>&nbsp;</td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right">&nbsp;<a accesskey="n" href="object-system-design.html">Next</a></td></tr><tr><td width="40%" align="left">Overview&nbsp;</td><td width="20%" align="center"><a accesskey="u" href="kernel-doc.html">Up</a></td><td width="40%" align="right">&nbsp;OpenACS 4 Object Model Design</td></tr></table><hr><address>rmello at fslc.usu.edu</address><address><a href="mailto:vinod@kurup.com">
-			vinod@kurup.com
-		  </a></address></div></body></html>
+requirements on relation types.</td><td>09/06/2000</td><td>Pete Su</td></tr><tr><td>0.9</td><td>Edited for ACS 4 Beta release.</td><td>09/30/2000</td><td>Kai Wu</td></tr></tbody></table></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="kernel-overview.html">Prev</a>&nbsp;</td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right">&nbsp;<a accesskey="n" href="object-system-design.html">Next</a></td></tr><tr><td width="40%" align="left">Overview&nbsp;</td><td width="20%" align="center"><a accesskey="u" href="kernel-doc.html">Up</a></td><td width="40%" align="right">&nbsp;OpenACS 4 Object Model Design</td></tr></table><hr><address>rmello at fslc.usu.edu</address><address><a href="mailto:vinod@kurup.com">vinod@kurup.com</a></address></div><a name="comments"></a><center><a href="http://openacs.org/doc/openacs-4/object-system-requirements.html#comments">View comments on this page at openacs.org</a></center></body></html>