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> </td><th width="60%" align="center">Chapter 7. Kernel Documentation</th><td width="20%" align="right"> <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> </td><th width="60%" align="center">Chapter�7.�Kernel Documentation</th><td width="20%" align="right"> <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 "scoping" was introduced into the core data model.</p><p>"Scope" 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 "hook into" 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 "scope" 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 "scope" 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 "contained" 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 "site-wide" 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 "object X is related to object Y by relationship R," 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 "instantiating" 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 "instantiating" 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 "delete cascade" 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 "delete cascade" 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 "hook into" 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> </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right"> <a accesskey="n" href="object-system-design.html">Next</a></td></tr><tr><td width="40%" align="left">Overview </td><td width="20%" align="center"><a accesskey="u" href="kernel-doc.html">Up</a></td><td width="40%" align="right"> 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> </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right"> <a accesskey="n" href="object-system-design.html">Next</a></td></tr><tr><td width="40%" align="left">Overview </td><td width="20%" align="center"><a accesskey="u" href="kernel-doc.html">Up</a></td><td width="40%" align="right"> 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>