[Zope3-checkins] SVN: Zope3/trunk/src/zope/app/ More typeos found upon more reading.

[Benji York]

Log message for revision 28697:
  More typeos found upon more reading.

Changed:
  U   Zope3/trunk/src/zope/app/pau/README.txt
  U   Zope3/trunk/src/zope/app/securitypolicy/zopepolicy.txt

-=-
Modified: Zope3/trunk/src/zope/app/pau/README.txt
===================================================================
--- Zope3/trunk/src/zope/app/pau/README.txt	2004-12-23 21:30:21 UTC (rev 28696)
+++ Zope3/trunk/src/zope/app/pau/README.txt	2004-12-23 21:44:30 UTC (rev 28697)
@@ -387,7 +387,7 @@
 -----------------------------
 
 To understand how the challenge plugins work, it's helpful to
-understand how the unauthorized method of authenticaton services 
+understand how the unauthorized method of authentication services 
 get called.
 
 If an 'Unauthorized' exception is raised and not caught by application
@@ -411,7 +411,7 @@
 ---------
 
 Sometimes, we want multiple challengers to work together.  For
-example, the HTTP specification allows multiple challenges to be isued
+example, the HTTP specification allows multiple challenges to be issued
 in a response.  A challenge plugin can provide a `protocol`
 attribute.  If multiple challenge plugins have the same protocol,
 then, if any of them are called and return True, then they will all be
@@ -534,7 +534,7 @@
   view that provides
   `zope.app.form.browser.interfaces.ISourceQueryView`.
 
-PAU uses search plugins in a very simple way.  It mearly implements
+PAU uses search plugins in a very simple way.  It merely implements
 `zope.schema.interfaces.ISourceQueriables`:
 
   >>> [id for (id, queriable) in auth.getQueriables()]

Modified: Zope3/trunk/src/zope/app/securitypolicy/zopepolicy.txt
===================================================================
--- Zope3/trunk/src/zope/app/securitypolicy/zopepolicy.txt	2004-12-23 21:30:21 UTC (rev 28696)
+++ Zope3/trunk/src/zope/app/securitypolicy/zopepolicy.txt	2004-12-23 21:44:30 UTC (rev 28697)
@@ -35,7 +35,7 @@
   >>> principal = Principal('bob')
 
 Roles and permissions are also represented by objects, however, for
-the purposes of the scurity policy, only string `ids` are used.
+the purposes of the security policy, only string `ids` are used.
 
 The security policy provides a factory for creating interactions:
 
@@ -50,7 +50,7 @@
 system for later execution.  When untrusted code is executing, the
 authors of the code participate in the interaction.  An
 interaction has a permission on an object only if all of the
-principals participataing in the interaction have access to the object.
+principals participating in the interaction have access to the object.
 
 The `checkPermission` method on interactions is used to test whether
 an interaction has a permission for an object.  An interaction without
@@ -81,7 +81,7 @@
   >>> interaction.checkPermission(CheckerPublic, ob)
   True
 
-We make grants and denials on objects by adaping them to various
+We make grants and denials on objects by adapting them to various
 granting interfaces.  The objects returned from the adaptation are 
 object-specific manager objects:
 
@@ -220,7 +220,7 @@
   >>> interaction.checkPermission('P3G', ob)
   True
 
-Local role-based grants do not override global prinicipal-specific denials:
+Local role-based grants do not override global principal-specific denials:
 
   >>> roleper.grantPermissionToRole('P1G', 'R1G')
   >>> prinrole.assignRoleToPrincipal('R1G', 'bob')
@@ -410,7 +410,7 @@
   >>> interaction.checkPermission('P3G', ob4)
   True
 
-We'll get the same result if we have a non-annotatble parent without a
+We'll get the same result if we have a non-annotatable parent without a
 parent:
 
   >>> ob3.__parent__ = C()
@@ -591,7 +591,7 @@
 
 Now, the principal has two groups. In one group, the permission 'gP2'
 is denied, but in the other, it is allowed.  In a case like this, the
-premission is allowed:
+permission is allowed:
 
   >>> interaction.checkPermission('gP2', ob2)
   True