Index: openacs-4/packages/acs-core-docs/www/object-system-design.html
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/object-system-design.html,v
diff -u -r1.37.2.3 -r1.37.2.4
--- openacs-4/packages/acs-core-docs/www/object-system-design.html	3 Sep 2021 09:15:18 -0000	1.37.2.3
+++ openacs-4/packages/acs-core-docs/www/object-system-design.html	1 Aug 2024 08:03:40 -0000	1.37.2.4
@@ -33,7 +33,7 @@
 object type (e.g. users) to instances of another object type (e.g.
 groups).
 </p></li></ul></div><p>The next section will explore these facilities in the context of the
-particular programming idioms that we wish to generalize.</p><p><span class="strong"><strong>Related Links</strong></span></p><p>This design document should be read along with the design documents for <a class="link" href="groups-design.html" title="Groups Design">the new groups system</a>, <a class="link" href="subsites-design.html" title="Subsites Design Document">subsites</a> and <a class="link" href="permissions-design.html" title="Permissions Design">the permissions system</a></p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a name="object-system-design-history"></a>History</h3></div></div></div><p>The motivation for most of the facilities in the OpenACS 4 Object Model can be
+particular programming idioms that we wish to generalize.</p><p><span class="strong"><strong>Related Links</strong></span></p><p>This design document should be read along with the design documents for <a class="link" href="groups-design.html" title="Groups Design">the new groups system</a>, <a class="link" href="subsites-design.html" title="Subsites Design Document">subsites</a> and <a class="link" href="permissions-design.html" title="Permissions Design">the permission system</a></p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a name="object-system-design-history"></a>History</h3></div></div></div><p>The motivation for most of the facilities in the OpenACS 4 Object Model can be
 understood in the context of the 3.x code base and the kinds of programming
 idioms that evolved there. These are listed and discussed below.</p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a name="objects-design-object-ident"></a>Object Identification</h4></div></div></div><p>Object identification is a central mechanism in OpenACS 4. Every application
 object in OpenACS 4 has a unique ID which is mapped to a row in a central table
@@ -77,7 +77,7 @@
 in the new system. Each row in <code class="computeroutput">acs_objects</code> stores information
 <span class="emphasis"><em>about</em></span> the application object, but not the application object itself.
 This becomes more clear if you skip ahead and look at the SQL schema code
-that defines this table.</p></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a name="objects-design-obj-context"></a>Object Context and Access Control</h4></div></div></div><p>Until the implementation of the general permissions system, every OpenACS
+that defines this table.</p></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a name="objects-design-obj-context"></a>Object Context and Access Control</h4></div></div></div><p>Until the implementation of the general permission 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 <code class="computeroutput">address_book</code> table:</p><div class="informaltable"><table class="informaltable" cellspacing="0" border="1"><colgroup><col><col><col><col><col></colgroup><tbody><tr><td><span class="strong"><strong>...</strong></span></td><td><span class="strong"><strong><code class="computeroutput">scope</code></strong></span></td><td><span class="strong"><strong><code class="computeroutput">user_id</code></strong></span></td><td><span class="strong"><strong><code class="computeroutput">group_id</code></strong></span></td><td><span class="strong"><strong>...</strong></span></td></tr><tr><td>...</td><td><code class="computeroutput">user</code></td><td><code class="computeroutput">123</code></td><td> </td><td>...</td></tr><tr><td>...</td><td><code class="computeroutput">group</code></td><td> </td><td><code class="computeroutput">456</code></td><td>...</td></tr><tr><td>...</td><td><code class="computeroutput">public</code></td><td> </td><td> </td><td>...</td></tr></tbody></table></div><p>The first row represents an entry in User 123's personal address book,
@@ -101,7 +101,7 @@
 to an object's context if there is no information about user X's
 permission to perform action Y on object Z.</p><p>The context system forms the basis for the rest of the OpenACS access control
 system, which is described in two separate documents: one for the
-<a class="link" href="permissions-design.html" title="Permissions Design">permissions system</a> and another for the
+<a class="link" href="permissions-design.html" title="Permissions Design">permission system</a> and another for the
 <a class="link" href="groups-design.html" title="Groups Design">party groups</a> system. The context system
 is also used to implement <a class="link" href="subsites-design.html" title="Subsites Design Document">subsites</a>.</p></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a name="objects-design-obj-types"></a>Object Types</h4></div></div></div><p>As mentioned above, many OpenACS modules provide extensible data models, and
 need to use application specific mechanisms to keep track of user defined