Index: openacs-4/packages/acs-core-docs/www/xml/kernel/object-system-design.xml
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/xml/kernel/object-system-design.xml,v
diff -u -r1.11.2.1 -r1.11.2.2
--- openacs-4/packages/acs-core-docs/www/xml/kernel/object-system-design.xml	14 Aug 2019 07:36:04 -0000	1.11.2.1
+++ openacs-4/packages/acs-core-docs/www/xml/kernel/object-system-design.xml	2 Jul 2020 08:39:25 -0000	1.11.2.2
@@ -474,7 +474,7 @@
 alternative. Here, some notion of subtyping is embedded into an existing SQL
 or SQL-like database engine. Examples of systems like this include the new
 Informix, PostgreSQL 7, and Oracle has something like this too. The main
-problem with these systems: each one implements their own non-portable
+problem with these systems: each one implements their own nonportable
 extensions to SQL to implement subtyping. Thus, making OpenACS data models
 portable would become even more difficult. In addition, each of these object
 systems have strange limitations that make using inheritance difficult in
@@ -499,7 +499,7 @@
 that the data model is not designed to scale too large type hierarchies. In
 the more limited domain of the metadata model, this is acceptable since the
 type hierarchy is fairly small. But the object system data model is not
-designed to support, for example, a huge type tree like the Java runtime
+designed to support, for example, a huge type tree like the Java run time
 libraries might define.</para>
 
 <para>This last point cannot be over-stressed: <emphasis role="strong">the object model is not