context finding -> resource location

10 files changed, 385 insertions, 530 deletions

diff --git a/docs/glossary.rst b/docs/glossary.rst
index a1f1ef769..fc6eda328 100644
--- a/docs/glossary.rst
+++ b/docs/glossary.rst
@@ -129,7 +129,7 @@ Glossary
      The default view of a :term:`resource` is the view invoked when the
      :term:`view name` is the empty string (``''``).  This is the case when
      :term:`traversal` exhausts the path elements in the PATH_INFO of a
-     request before it returns a :term:`context`.
+     request before it returns a :term:`context` resource.
 
    virtualenv
      An isolated Python environment.  Allows you to control which
@@ -143,12 +143,12 @@ Glossary
      the resource tree traversed by the system.  When traversal is used, a
      resource becomes the :term:`context` of a :term:`view`.  If :mod:`url
      dispatch` is used, a single resource is generated for each request and
-     is used as the context of a view.
+     is used as the context resource of a view.
 
    resource tree
      A nested set of dictionary-like objects, each of which is a
      :term:`resource`.  The act of :term:`traversal` uses the resource tree
-     to find a :term:`context`.
+     to find a :term:`context` resource.
 
    domain model
      Persistent data related to your application.  For example, data stored
@@ -157,13 +157,13 @@ Glossary
 
    traversal
      The act of descending "up" a tree of resource objects from a root
-     resource in order to find a :term:`context`.  The :app:`Pyramid`
-     :term:`router` performs traversal of resource objects when a :term:`root
-     factory` is specified.  See the :ref:`traversal_chapter` chapter for
-     more information.  Traversal can be performed *instead* of :term:`URL
-     dispatch` or can be combined *with* URL dispatch.  See
-     :ref:`hybrid_chapter` for more information about combining traversal and
-     URL dispatch (advanced).
+     resource in order to find a :term:`context` resource.  The
+     :app:`Pyramid` :term:`router` performs traversal of resource objects
+     when a :term:`root factory` is specified.  See the
+     :ref:`traversal_chapter` chapter for more information.  Traversal can be
+     performed *instead* of :term:`URL dispatch` or can be combined *with*
+     URL dispatch.  See :ref:`hybrid_chapter` for more information about
+     combining traversal and URL dispatch (advanced).
 
    router
      The :term:`WSGI` application created when you start a
@@ -174,21 +174,21 @@ Glossary
 
    URL dispatch
      An alternative to :term:`traversal` as a mechanism for locating a
-     :term:`context` for a :term:`view`.  When you use a :term:`route`
-     in your :app:`Pyramid` application via a :term:`route
+     :term:`context` resource for a :term:`view`.  When you use a
+     :term:`route` in your :app:`Pyramid` application via a :term:`route
      configuration`, you are using URL dispatch. See the
      :ref:`urldispatch_chapter` for more information.
 
    context
-     An object in the system that is found during :term:`traversal` or
-     :term:`URL dispatch` based on URL data; if it's found via traversal,
+     An resource in the resource tree that is found during :term:`traversal`
+     or :term:`URL dispatch` based on URL data; if it's found via traversal,
      it's usually a :term:`resource` object that is part of a resource tree;
      if it's found via :term:`URL dispatch`, it's a object manufactured on
-     behalf of the route's "factory".  A context becomes the subject of a
-     :term:`view`, and typically has security information attached to it.
-     See the :ref:`traversal_chapter` chapter and the
+     behalf of the route's "factory".  A context resource becomes the subject
+     of a :term:`view`, and often has security information attached to
+     it.  See the :ref:`traversal_chapter` chapter and the
      :ref:`urldispatch_chapter` chapter for more information about how a URL
-     is resolved to a context.
+     is resolved to a context resource.
 
    application registry
      A registry of configuration information consulted by
@@ -209,14 +209,14 @@ Glossary
 
    permission
      A string or unicode object that represents an action being taken against
-     a context.  A permission is associated with a view name and a resource
-     type by the developer.  Resources are decorated with security
-     declarations (e.g. an :term:`ACL`), which reference these tokens also.
-     Permissions are used by the active to security policy to match the view
-     permission against the resources's statements about which permissions
-     are granted to which principal in a context in order to to answer the
-     question "is this user allowed to do this".  Examples of permissions:
-     ``read``, or ``view_blog_entries``.
+     a :term:`context` resource.  A permission is associated with a view name
+     and a resource type by the developer.  Resources are decorated with
+     security declarations (e.g. an :term:`ACL`), which reference these
+     tokens also.  Permissions are used by the active to security policy to
+     match the view permission against the resources's statements about which
+     permissions are granted to which principal in a context in order to to
+     answer the question "is this user allowed to do this".  Examples of
+     permissions: ``read``, or ``view_blog_entries``.
 
    default permission
      A :term:`permission` which is registered as the default for an
@@ -235,16 +235,16 @@ Glossary
      group), and a :term:`permission`.  For example the ACE, ``(Allow,
      'bob', 'read')`` is a member of an ACL that indicates that the
      principal ``bob`` is allowed the permission ``read`` against the
-     context the ACL is attached to.
+     resource the ACL is attached to.
 
    ACL
-     An *access control list*.  An ACL is a sequence of :term:`ACE`
-     tuples.  An ACL is attached to a resource instance.  An example of an
-     ACL is ``[ (Allow, 'bob', 'read'), (Deny, 'fred', 'write')]``.  If
-     an ACL is attached to a resource instance, and that resource is
-     findable via the context, it will be consulted any active security
-     policy to determine wither a particular request can be fulfilled
-     given the :term:`authentication` information in the request.
+     An *access control list*.  An ACL is a sequence of :term:`ACE` tuples.
+     An ACL is attached to a resource instance.  An example of an ACL is ``[
+     (Allow, 'bob', 'read'), (Deny, 'fred', 'write')]``.  If an ACL is
+     attached to a resource instance, and that resource is findable via the
+     context resource, it will be consulted any active security policy to
+     determine wither a particular request can be fulfilled given the
+     :term:`authentication` information in the request.
 
    authentication
      The act of determining that the credentials a user presents
@@ -253,12 +253,12 @@ Glossary
      policy`.
 
    authorization
-     The act of determining whether a user can perform a specific
-     action.  In pyramid terms, this means determining whether, for a
-     given context, any :term:`principal` (or principals) associated
-     with the request have the requisite :term:`permission` to allow
-     the request to continue.  Authorization in :app:`Pyramid` is
-     performed via its :term:`authorization policy`.
+     The act of determining whether a user can perform a specific action.  In
+     pyramid terms, this means determining whether, for a given resource, any
+     :term:`principal` (or principals) associated with the request have the
+     requisite :term:`permission` to allow the request to continue.
+     Authorization in :app:`Pyramid` is performed via its
+     :term:`authorization policy`.
 
    principal
      A *principal* is a string or unicode object representing a userid
@@ -274,7 +274,7 @@ Glossary
      code which has an API which determines whether or not the
      principals associated with the request can perform an action
      associated with a permission, based on the information found on the
-     :term:`context`.
+     :term:`context` resource.
 
    authentication policy
      An authentication policy in :app:`Pyramid` terms is a bit of
@@ -415,9 +415,10 @@ Glossary
      documentation is authored in ReStructuredText format.
 
    root
-     The object at which :term:`traversal` begins when
-     :app:`Pyramid` searches for a :term:`context` (for :term:`URL
-     Dispatch`, the root is *always* the context).
+     The object at which :term:`traversal` begins when :app:`Pyramid`
+     searches for a :term:`context` resource (for :term:`URL Dispatch`, the
+     root is *always* the context resource unless the ``traverse=`` argument 
+     is used in route configuration).
 
    subpath
      A list of element "left over" after the :term:`router` has
@@ -496,12 +497,12 @@ Glossary
      use.
 
    lineage
-     An ordered sequence of objects based on a ":term:`location`
-     -aware" context.  The lineage of any given :term:`context` is
-     composed of itself, its parent, its parent's parent, and so on.
-     The order of the sequence is context-first, then the parent of the
-     context, then its parent's parent, and so on.  The parent of an
-     object in a lineage is available as its ``__parent__`` attribute.
+     An ordered sequence of objects based on a ":term:`location` -aware"
+     resource.  The lineage of any given :term:`resource` is composed of
+     itself, its parent, its parent's parent, and so on.  The order of the
+     sequence is resource-first, then the parent of the resource, then its
+     parent's parent, and so on.  The parent of a resource in a lineage is
+     available as its ``__parent__`` attribute.
 
    root factory
      The "root factory" of an :app:`Pyramid` application is called
@@ -679,19 +680,12 @@ Glossary
 
    View Lookup
      The act of finding and invoking the "best" :term:`view callable`
-     given a :term:`request`, a :term:`context`, and a :term:`view
-     name`.
-
-   Context Finding
-     The act of locating a :term:`context` and a :term:`view name`
-     given a :term:`request`.  :term:`Traversal` and :term:`URL
-     dispatch` are the context finding subsystems used by
-     :app:`Pyramid`.
-
-   Triad
-     The three bits of information used by :term:`view lookup` to find
-     "the best" view callable for a given circumstance: a
-     :term:`context` type, a :term:`view name` and a :term:`request`.
+     given a :term:`request` and a :term:`context` resource.
+
+   Resource Location
+     The act of locating a :term:`context` resource given a :term:`request`.
+     :term:`Traversal` and :term:`URL dispatch` are the resource location
+     subsystems used by :app:`Pyramid`.
 
    Google App Engine
      `Google App Engine <http://code.google.com/appengine/>`_ (aka
diff --git a/docs/index.rst b/docs/index.rst
index 3add95117..188c2b518 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -38,7 +38,7 @@ Narrative documentation in chapter form explaining how to use
    narr/firstapp
    narr/project
    narr/startup
-   narr/contextfinding
+   narr/resourcelocation
    narr/traversal
    narr/urldispatch
    narr/hybrid
diff --git a/docs/latexindex.rst b/docs/latexindex.rst
index 09e449fe3..52389e421 100644
--- a/docs/latexindex.rst
+++ b/docs/latexindex.rst
@@ -31,7 +31,7 @@ Narrative Documentation
    narr/configuration
    narr/firstapp
    narr/project
-   narr/contextfinding
+   narr/resourcelocation
    narr/traversal
    narr/urldispatch
    narr/hybrid
diff --git a/docs/narr/contextfinding.rst b/docs/narr/contextfinding.rst
deleted file mode 100644
index ad0d1f9da..000000000
--- a/docs/narr/contextfinding.rst
+++ /dev/null
@@ -1,117 +0,0 @@
-.. index::
-   single: context finding
-
-.. _contextfinding_chapter:
-
-Context Finding and View Lookup
--------------------------------
-
-In order for a web application to perform any useful action, the web
-framework must provide a mechanism to find and invoke code written by
-the application developer based on parameters present in the
-:term:`request`.
-
-:app:`Pyramid` uses two separate but cooperating subsystems to find
-and invoke code written by the application developer: :term:`context
-finding` and :term:`view lookup`.
-
-- A :app:`Pyramid` :term:`context finding` subsystem is given a
-  :term:`request`; it is responsible for finding a :term:`context`
-  object and a :term:`view name` based on information present in the
-  request.
-
-- Using the context and view name provided by :term:`context finding`,
-  the :app:`Pyramid` :term:`view lookup` subsystem is provided with
-  a :term:`request`, a :term:`context` and a :term:`view name`.  It is
-  then responsible for finding and invoking a :term:`view callable`.
-  A view callable is a specific bit of code written and registered by
-  the application developer which receives the :term:`request` and
-  which returns a :term:`response`.
-
-These two subsystems are used by :app:`Pyramid` serially:
-first, a :term:`context finding` subsystem does its job.  Then the
-result of context finding is passed to the :term:`view lookup`
-subsystem.  The view lookup system finds a :term:`view callable`
-written by an application developer, and invokes it.  A view callable
-returns a :term:`response`.  The response is returned to the
-requesting user.
-
-.. sidebar::  What Good is A Context Finding Subsystem?
-
-   The :term:`URL dispatch` mode of :app:`Pyramid` as well as many
-   other web frameworks such as :term:`Pylons` or :term:`Django`
-   actually collapse the two steps of context finding and view lookup
-   into a single step.  In these systems, a URL can map *directly* to
-   a view callable.  This makes them simpler to understand than
-   systems which use distinct subsystems to locate a context and find
-   a view.  However, explicitly finding a context provides extra
-   flexibility.  For example, it makes it possible to protect your
-   application with declarative context-sensitive instance-level
-   :term:`authorization`, which is not well-supported in frameworks
-   that do not provide a notion of a context.
-
-There are two separate :term:`context finding` subsystems in
-:app:`Pyramid`: :term:`traversal` and :term:`URL dispatch`. They can
-be used separately or they can be combined.  Three chapters which
-follow describe :term:`context finding`: :ref:`traversal_chapter`,
-:ref:`urldispatch_chapter` and :ref:`hybrid_chapter`.
-
-There is only one :term:`view lookup` subsystem present in
-:app:`Pyramid`.  Where appropriate, we will describe how view lookup
-interacts with context finding.  One chapter which follows describes
-:term:`view lookup`: :ref:`views_chapter`.
-
-Should I Use Traversal or URL Dispatch for Context Finding?
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-:term:`URL dispatch` is very straightforward.  When you limit your
-application to using URL dispatch, you know every URL that your
-application might generate or respond to, all the URL matching
-elements are listed in a single place, and you needn't think about
-:term:`context finding` or :term:`view lookup` at all.
-
-URL dispatch can easily handle URLs such as
-``http://example.com/members/Chris``, where it's assumed that each
-item "below" ``members`` in the URL represents a single member in some
-system.  You just match everything "below" ``members`` to a particular
-:term:`view callable`, e.g. ``/members/{memberid}``.
-
-However, URL dispatch is not very convenient if you'd like your URLs
-to represent an arbitrary hierarchy.  For example, if you need to
-infer the difference between sets of URLs such as these, where the
-``document`` in the first URL represents a PDF document, and
-``/stuff/page`` in the second represents an OpenOffice document in a
-"stuff" folder.
-
-.. code-block:: text
-
-   http://example.com/members/Chris/document
-   http://example.com/members/Chris/stuff/page
-
-It takes more pattern matching assertions to be able to make
-hierarchies work in URL-dispatch based systems, and some assertions
-just aren't possible.  Essentially, URL-dispatch based systems just
-don't deal very well with URLs that represent arbitrary-depth
-hierarchies.
-
-But :term:`traversal` *does* work well for URLs that represent
-arbitrary-depth hierarchies.  Since the path segments that compose a URL are
-addressed separately, it becomes very easy to form URLs that represent
-arbitrary depth hierarchies in a system that uses traversal.  When you're
-willing to treat your application resources as a tree that can be traversed,
-it also becomes easy to provide "instance-level security": you just attach a
-security declaration to each instance in the tree.  This is not nearly as
-easy to do when using URL dispatch.
-
-In essence, the choice to use traversal vs. URL dispatch is largely
-religious.  Traversal dispatch probably just doesn't make any sense
-when you possess completely "square" data stored in a relational
-database because it requires the construction and maintenance of a
-tree and requires that the developer think about mapping URLs to code
-in terms of traversing that tree.  However, when you have a
-hierarchical data store, using traversal can provide significant
-advantages over using URL-based dispatch.
-
-Since :app:`Pyramid` provides support for both approaches, you can
-use either exclusively or combine them as you see fit.
-
diff --git a/docs/narr/declarative.rst b/docs/narr/declarative.rst
index 28dec4ff1..deccb6c48 100644
--- a/docs/narr/declarative.rst
+++ b/docs/narr/declarative.rst
@@ -563,7 +563,7 @@ example of a view declaration in ZCML is as follows:
     />
 
 The above maps the ``.views.hello_world`` view callable function to
-the following set of :term:`context finding` results:
+the following set of :term:`resource location` results:
 
 - A :term:`context` object which is an instance (or subclass) of the
   Python class represented by ``.resources.Hello``
@@ -593,12 +593,11 @@ You can also declare a *default view callable* for a :term:`resource` type:
      view=".views.hello_world"
     />
 
-A *default view callable* simply has no ``name`` attribute.  For the
-above registration, when a :term:`context` is found that is of the
-type ``.resources.Hello`` and there is no :term:`view name` associated
-with the result of :term:`context finding`, the *default view
-callable* will be used.  In this case, it's the view at
-``.views.hello_world``.
+A *default view callable* simply has no ``name`` attribute.  For the above
+registration, when a :term:`context` is found that is of the type
+``.resources.Hello`` and there is no :term:`view name` associated with the
+result of :term:`resource location`, the *default view callable* will be
+used.  In this case, it's the view at ``.views.hello_world``.
 
 A default view callable can alternately be defined by using the empty
 string as its ``name`` attribute:
diff --git a/docs/narr/hybrid.rst b/docs/narr/hybrid.rst
index f9dab9ff6..181ae1285 100644
--- a/docs/narr/hybrid.rst
+++ b/docs/narr/hybrid.rst
@@ -3,12 +3,11 @@
 Combining Traversal and URL Dispatch
 ====================================
 
-When you write most :app:`Pyramid` applications, you'll be using
-one or the other of two available :term:`context finding` subsystems:
-traversal or URL dispatch.  However, to solve a limited set of
-problems, it's useful to use *both* traversal and URL dispatch
-together within the same application.  :app:`Pyramid` makes this
-possible via *hybrid* applications.
+When you write most :app:`Pyramid` applications, you'll be using one or the
+other of two available :term:`resource location` subsystems: traversal or URL
+dispatch.  However, to solve a limited set of problems, it's useful to use
+*both* traversal and URL dispatch together within the same application.
+:app:`Pyramid` makes this possible via *hybrid* applications.
 
 .. warning::
 
@@ -92,8 +91,8 @@ application, :term:`traversal` is performed during a request after a
 route has already matched.  This means that the URL pattern that
 represents the ``pattern`` argument of a route must match the
 ``PATH_INFO`` of a request, and after the route pattern has matched,
-most of the "normal" rules of traversal with respect to :term:`context
-finding` and :term:`view lookup` apply.
+most of the "normal" rules of traversal with respect to :term:`resource
+location` and :term:`view lookup` apply.
 
 There are only four real differences between a purely traversal-based
 application and a hybrid application:
@@ -200,20 +199,19 @@ remainder becomes the path used to perform traversal.
 Note that unlike the examples provided within :ref:`urldispatch_chapter`, the
 ``add_route`` configuration statement named previously does not pass a
 ``view`` argument.  This is because a hybrid mode application relies on
-:term:`traversal` to do :term:`context finding` and :term:`view lookup`
+:term:`traversal` to do :term:`resource location` and :term:`view lookup`
 instead of invariably invoking a specific view callable named directly within
 the matched route's configuration.
 
 Because the pattern of the above route ends with ``*traverse``, when this
-route configuration is matched during a request, :app:`Pyramid`
-will attempt to use :term:`traversal` against the :term:`root` object
-implied by the :term:`root factory` that is implied by the route's
-configuration.  Since no ``root_factory`` argument is explicitly specified
-for this route, this will either be the *global* root factory
-for the application, or the *default* root factory. 
-Once :term:`traversal` has found a :term:`context`,
-:term:`view lookup` will be invoked in almost exactly the same way it
-would have been invoked in a "pure" traversal-based application.
+route configuration is matched during a request, :app:`Pyramid` will attempt
+to use :term:`traversal` against the :term:`root` object implied by the
+:term:`root factory` that is implied by the route's configuration.  Since no
+``root_factory`` argument is explicitly specified for this route, this will
+either be the *global* root factory for the application, or the *default*
+root factory.  Once :term:`traversal` has found a :term:`context` resource,
+:term:`view lookup` will be invoked in almost exactly the same way it would
+have been invoked in a "pure" traversal-based application.
 
 Let's assume there is no *global* :term:`root factory` configured in
 this application. The *default* :term:`root factory` cannot be traversed: 
@@ -272,9 +270,9 @@ When the route configuration named ``home`` above is matched during a
 request, the matchdict generated will be based on its pattern:
 ``{foo}/{bar}/*traverse``.  The "capture value" implied by the ``*traverse``
 element in the pattern will be used to traverse the resource tree in order to
-find a context, starting from the root object returned from the root factory.
-In the above example, the :term:`root` object found will be the instance
-named ``root`` in ``routes.py``.
+find a context resource, starting from the root object returned from the root
+factory.  In the above example, the :term:`root` object found will be the
+instance named ``root`` in ``routes.py``.
 
 If the URL that matched a route with the pattern ``{foo}/{bar}/*traverse``,
 is ``http://example.com/one/two/a/b/c``, the traversal path used
@@ -283,10 +281,10 @@ against the root object will be ``a/b/c``.  As a result,
 ``b``, and ``c``, beginning at the root object.
 
 In our above example, this particular set of traversal steps will mean that
-the :term:`context` of the view would be the ``Traversable`` object we've
-named ``c`` in our bogus resource tree and the :term:`view name` resulting
-from traversal will be the empty string; if you need a refresher about why
-this outcome is presumed, see :ref:`traversal_algorithm`.
+the :term:`context` resource of the view would be the ``Traversable`` object
+we've named ``c`` in our bogus resource tree and the :term:`view name`
+resulting from traversal will be the empty string; if you need a refresher
+about why this outcome is presumed, see :ref:`traversal_algorithm`.
 
 At this point, a suitable view callable will be found and invoked
 using :term:`view lookup` as described in :ref:`view_configuration`,
@@ -319,7 +317,7 @@ The above ``mypackage.views.myview`` view callable will be invoked when:
 
 - the :term:`view name` resulting from traversal is the empty string.
 
-- the :term:`context` is any object.
+- the :term:`context` resource is any object.
 
 It is also possible to declare alternate views that may be invoked
 when a hybrid route is matched:
@@ -341,7 +339,7 @@ above ``mypackage.views.another_view`` view will be invoked when:
 
 - the :term:`view name` resulting from traversal is ``another``.
 
-- the :term:`context` is any object.
+- the :term:`context` resource is any object.
 
 For instance, if the URL ``http://example.com/one/two/a/another`` is provided
 to an application that uses the previously mentioned resource tree, the
diff --git a/docs/narr/security.rst b/docs/narr/security.rst
index 469d3d298..c045e3b32 100644
--- a/docs/narr/security.rst
+++ b/docs/narr/security.rst
@@ -6,20 +6,20 @@
 Security
 ========
 
-:app:`Pyramid` provides an optional declarative authorization
-system that prevents a :term:`view` from being invoked when the user
-represented by credentials in the :term:`request` does not have an
-appropriate level of access within a particular :term:`context`.
-Here's how it works at a high level:
+:app:`Pyramid` provides an optional declarative authorization system that
+prevents a :term:`view` from being invoked when the user represented by
+credentials in the :term:`request` does not have an appropriate level of
+access when a particular resource is the :term:`context`.  Here's how it
+works at a high level:
 
 - A :term:`request` is generated when a user visits our application.
 
-- Based on the request, a :term:`context` is located through
-  :term:`context finding`.  A context is located differently depending
-  on whether the application uses :term:`traversal` or :term:`URL
-  dispatch`, but a context is ultimately found in either case.  See
-  :ref:`contextfinding_chapter` for more information about context
-  finding.
+- Based on the request, a :term:`context` resource is located through
+  :term:`resource location`.  A context is located differently depending on
+  whether the application uses :term:`traversal` or :term:`URL dispatch`, but
+  a context is ultimately found in either case.  See
+  :ref:`resourcelocation_chapter` for more information about resource
+  location.
 
 - A :term:`view callable` is located by :term:`view lookup` using the
   context as well as other attributes of the request.
@@ -119,15 +119,16 @@ You can also enable a security policy declaratively via ZCML.  See
 Protecting Views with Permissions
 ---------------------------------
 
-To protect a :term:`view callable` from invocation based on a user's
-security settings in a :term:`context`, you must pass a
-:term:`permission` to :term:`view configuration`.  Permissions are
-usually just strings, and they have no required composition: you can
-name permissions whatever you like.
+To protect a :term:`view callable` from invocation based on a user's security
+settings when a particular type of resource becomes the :term:`context`, you
+must pass a :term:`permission` to :term:`view configuration`.  Permissions
+are usually just strings, and they have no required composition: you can name
+permissions whatever you like.
 
 For example, the following view declaration protects the view named
-``add_entry.html`` when invoked against a ``Blog`` context with the ``add``
-permission using the :meth:`pyramid.config.Configurator.add_view` API:
+``add_entry.html`` when the context resource is of type ``Blog`` with the
+``add`` permission using the :meth:`pyramid.config.Configurator.add_view`
+API:
 
 .. code-block:: python
    :linenos:
@@ -160,9 +161,9 @@ Or the same thing can be done using the ``permission`` attribute of the ZCML
 As a result of any of these various view configuration statements, if an
 authorization policy is in place when the view callable is found during
 normal application operations, the requesting user will need to possess the
-``add`` permission against the :term:`context` to be able to invoke the
-``blog_entry_add_view`` view.  If he does not, the :term:`Forbidden view`
-will be invoked.
+``add`` permission against the :term:`context` resource in order to be able
+to invoke the ``blog_entry_add_view`` view.  If he does not, the
+:term:`Forbidden view` will be invoked.
 
 .. _setting_a_default_permission:
 
@@ -212,12 +213,12 @@ Assigning ACLs to your Resource Objects
 ---------------------------------------
 
 When the default :app:`Pyramid` :term:`authorization policy` determines
-whether a user possesses a particular permission in a :term:`context`, it
-examines the :term:`ACL` associated with the context.  An ACL is associated
-with a context by virtue of the ``__acl__`` attribute of the resource object
-representing the :term:`context`.  This attribute can be defined on the
-resource *instance* if you need instance-level security, or it can be defined
-on the resource *class* if you just need type-level security.
+whether a user possesses a particular permission with respect to a resource,
+it examines the :term:`ACL` associated with the resource.  An ACL is
+associated with a resource by adding an ``__acl__`` attribute to the resource
+object.  This attribute can be defined on the resource *instance* if you need
+instance-level security, or it can be defined on the resource *class* if you
+just need type-level security.
 
 For example, an ACL might be attached to the resource for a blog via its
 class:
@@ -414,14 +415,13 @@ module.  These can be imported for use in ACLs.
 Special ACEs
 ------------
 
-A convenience :term:`ACE` is defined representing a deny to everyone
-of all permissions in :data:`pyramid.security.DENY_ALL`.  This ACE
-is often used as the *last* ACE of an ACL to explicitly cause
-inheriting authorization policies to "stop looking up the traversal
-tree" (effectively breaking any inheritance).  For example, an ACL
-which allows *only* ``fred`` the view permission in a particular
-traversal context despite what inherited ACLs may say when the default
-authorization policy is in effect might look like so:
+A convenience :term:`ACE` is defined representing a deny to everyone of all
+permissions in :data:`pyramid.security.DENY_ALL`.  This ACE is often used as
+the *last* ACE of an ACL to explicitly cause inheriting authorization
+policies to "stop looking up the traversal tree" (effectively breaking any
+inheritance).  For example, an ACL which allows *only* ``fred`` the view
+permission for a particular resource despite what inherited ACLs may say when
+the default authorization policy is in effect might look like so:
 
 .. code-block:: python
    :linenos:
diff --git a/docs/narr/traversal.rst b/docs/narr/traversal.rst
index 9bc6014cd..98a009341 100644
--- a/docs/narr/traversal.rst
+++ b/docs/narr/traversal.rst
@@ -3,10 +3,10 @@
 Traversal
 =========
 
-:term:`Traversal` is a :term:`context finding` mechanism. It is the act of
-finding a :term:`context` and a :term:`view name` by walking over a
-:term:`resource tree`, starting from a :term:`root` resource, using a
-:term:`request` object as a source of path information.
+:term:`Traversal` is a :term:`resource location` mechanism. It is the act of
+finding a :term:`context` resource by walking over a :term:`resource tree`,
+starting from a :term:`root` resource, using a :term:`request` object as a
+source of path information.
 
 In this chapter, we'll provide a high-level overview of traversal, we'll
 explain the concept of a resource tree, and we'll show how traversal might be
@@ -58,22 +58,21 @@ The contents of ``myfile`` are now printed on the user's behalf.
 :app:`Pyramid` is very much like this inexperienced UNIX user as it uses
 :term:`traversal` against a resource tree.  In this analogy, we can map the
 ``cat`` program to the :app:`Pyramid` concept of a :term:`view callable`: it
-is a program that can be run against some :term:`context` as the result of
-:term:`view lookup`.  The file being operated on in this analogy is the
-:term:`context` object; the context is the "last resource found" in a
-traversal.  The directory structure is the resource tree being traversed.
-The act of progressively changing directories to find the file as well as the
-handling of a ``cd`` error as a stop condition is analogous to
+is a program that can be run against some :term:`resource` (the "context") as
+the result of :term:`view lookup`.  The file being operated on in this
+analogy is the :term:`context` resource; the context is the "last resource
+found" in a traversal.  The directory structure is the resource tree being
+traversed.  The act of progressively changing directories to find the file as
+well as the handling of a ``cd`` error as a stop condition is analogous to
 :term:`traversal`.
 
-The analogy we've used is not *exactly* correct, because, while the
-naive user already knows which command he wants to invoke before he
-starts "traversing" (``cat``), :app:`Pyramid` needs to obtain that
-information from the path being traversed itself.  In
-:term:`traversal`, the "command" meant to be invoked is a :term:`view
-callable`.  A view callable is derived via :term:`view lookup` from
-the combination of the :term:`view name` and the :term:`context`.
-Traversal is the act of obtaining these two items.
+The analogy we've used is not *exactly* correct, because, while the naive
+user already knows which command he wants to invoke before he starts
+"traversing" (``cat``), :app:`Pyramid` needs to obtain that information from
+the path being traversed itself.  In :term:`traversal`, the "command" meant
+to be invoked is a :term:`view callable`.  A view callable is derived via
+:term:`view lookup` from the combination of the :term:`request` and the
+:term:`context`.
 
 .. index::
    single: traversal overview
@@ -81,49 +80,48 @@ Traversal is the act of obtaining these two items.
 A High-Level Overview of Traversal
 ----------------------------------
 
-:term:`Traversal` is dependent on information in a :term:`request`
-object.  Every :term:`request` object contains URL path information in
-the ``PATH_INFO`` portion of the :term:`WSGI` environment.  The
-``PATH_INFO`` portion of the WSGI environment is the portion of a
-request's URL following the hostname and port number, but before any
-query string elements or fragment element.  For example the
-``PATH_INFO`` portion of the URL
+:term:`Traversal` is dependent on information in a :term:`request` object.
+Every :term:`request` object contains URL path information in the
+``PATH_INFO`` portion of the :term:`WSGI` environment.  The ``PATH_INFO``
+portion of the WSGI environment is the portion of a request's URL following
+the hostname and port number, but before any query string elements or
+fragment element.  For example the ``PATH_INFO`` portion of the URL
 ``http://example.com:8080/a/b/c?foo=1`` is ``/a/b/c``.
 
-Traversal treats the ``PATH_INFO`` segment of a URL as a sequence of
-path segments.  For example, the ``PATH_INFO`` string ``/a/b/c`` is
-converted to the sequence ``['a', 'b', 'c']``.
+Traversal treats the ``PATH_INFO`` segment of a URL as a sequence of path
+segments.  For example, the ``PATH_INFO`` string ``/a/b/c`` is converted to
+the sequence ``['a', 'b', 'c']``.
 
 After the path info is converted, a lookup is performed against the resource
 tree for each path segment.  Each lookup uses the ``__getitem__`` method of
-an object in the tree.
+a resource in the tree.
 
 For example, if the path info sequence is ``['a', 'b', 'c']``:
 
 - :term:`Traversal` pops the first element (``a``) from the path
-  segment sequence and attempts to call the root object's
+  segment sequence and attempts to call the root resource's
   ``__getitem__`` method using that value (``a``) as an argument;
   we'll presume it succeeds.
 
-- When the root object's ``__getitem__`` succeeds it will return an
-  object, which we'll call "A".  The :term:`context` temporarily
-  becomes the "A" object.
+- When the root resource's ``__getitem__`` succeeds it will return another
+  resource, which we'll call "A".  The :term:`context` temporarily becomes
+  the "A" resource.
 
 - The next segment (``b``) is popped from the path sequence, and the
-  "A" object's ``__getitem__`` is called with that value (``b``) as an
+  "A" resource's ``__getitem__`` is called with that value (``b``) as an
   argument; we'll presume it succeeds.
 
-- When the "A" object's ``__getitem__`` succeeds it will return an
-  object, which we'll call "B".  The :term:`context` temporarily
-  becomes the "B" object.
+- When the "A" resource's ``__getitem__`` succeeds it will return another
+  resource, which we'll call "B".  The :term:`context` temporarily
+  becomes the "B" resource.
 
-This process continues until the path segment sequence is exhausted or
-a lookup for a path element fails.  In either case, a :term:`context`
+This process continues until the path segment sequence is exhausted or a
+lookup for a path element fails.  In either case, a :term:`context` resouce
 is found.
 
 Traversal "stops" when it either reaches a leaf level resource in your
 resource tree or when the path segments implied by the URL "run out".  The
-object that traversal "stops on" becomes the :term:`context`.  If at any
+resource that traversal "stops on" becomes the :term:`context`.  If at any
 point during traversal any resource in the tree doesn't have a
 ``__getitem__`` method, or if the ``__getitem__`` method of a resource raises
 a :exc:`KeyError`, traversal ends immediately, and that resource becomes the
@@ -132,14 +130,13 @@ a :exc:`KeyError`, traversal ends immediately, and that resource becomes the
 The results of a :term:`traversal` also include a :term:`view name`.
 The :term:`view name` is the *first* URL path segment in the set of
 ``PATH_INFO`` segments "left over" in the path segment list popped by
-the traversal process *after* traversal finds a context object.
+the traversal process *after* traversal finds a context resource.
 
-The combination of the :term:`context` object and the :term:`view
-name` found via traversal is used later in the same request by a
-separate :app:`Pyramid` subsystem -- the :term:`view lookup`
-subsystem -- to find a :term:`view callable` later within the same
-request.  How :app:`Pyramid` performs view lookup is explained
-within the :ref:`views_chapter` chapter.
+The combination of the context resource and the :term:`view name` found via
+traversal is used later in the same request by a separate :app:`Pyramid`
+subsystem -- the :term:`view lookup` subsystem -- to find a :term:`view
+callable` later within the same request.  How :app:`Pyramid` performs view
+lookup is explained within the :ref:`views_chapter` chapter.
 
 .. index::
    single: object tree
@@ -153,9 +150,9 @@ The Resource Tree
 
 When your application uses :term:`traversal` to resolve URLs to code, your
 application must supply the a resource tree to :app:`Pyramid`.  This tree is
-represented by a :term:`root` object.
+represented by a :term:`root` resource.
 
-In order to supply a root object for an application, at system startup
+In order to supply a root resource for an application, at system startup
 time, the :app:`Pyramid` :term:`Router` is configured with a
 callback known as a :term:`root factory`.  The root factory is
 supplied by the application developer as the ``root_factory`` argument
@@ -179,27 +176,24 @@ named ``config``:
 
    config = Configurator(root_factory=Root)
 
-Using the ``root_factory`` argument to a
-:class:`pyramid.config.Configurator` constructor tells your
-:app:`Pyramid` application to call this root factory to generate a
-root object whenever a request enters the application.  This root
-factory is also known as the global root factory.  A root factory can
-alternately be passed to the ``Configurator`` as a :term:`dotted
-Python name` which refers to a root factory object defined in a
-different module.
+Using the ``root_factory`` argument to a :class:`pyramid.config.Configurator`
+constructor tells your :app:`Pyramid` application to call this root factory
+to generate a root resource whenever a request enters the application.  This
+root factory is also known as the global root factory.  A root factory can
+alternately be passed to the ``Configurator`` as a :term:`dotted Python name`
+which refers to a root factory defined in a different module.
 
 A root factory is passed a :term:`request` object and it is expected to
-return an object which represents the root of the resource tree.  All
-:term:`traversal` will begin at this root object.  Usually a root factory for
-a traversal-based application will be more complicated than the above
-``Root`` object; in particular it may be associated with a database
-connection or another persistence mechanism.  A root object is often an
-instance of a class which has a ``__getitem__`` method.
+return a resource which represents the root of the resource tree.  All
+:term:`traversal` will begin at this root resource.  Usually a root factory
+for a traversal-based application will be more complicated than the above
+``Root`` class; in particular it may be associated with a database
+connection or another persistence mechanism.
 
 If no :term:`root factory` is passed to the :app:`Pyramid`
 :term:`Configurator` constructor, or the ``root_factory`` is specified
 as the value ``None``, a *default* root factory is used.  The default
-root factory always returns an object that has no child resources.
+root factory always returns a resource that has no child resources.
 
 .. sidebar:: Emulating the Default Root Factory
 
@@ -218,8 +212,8 @@ root factory always returns an object that has no child resources.
 
    The default root factory is just a really stupid object that has no
    behavior or state.  Using :term:`traversal` against an application that
-   uses the resource tree supplied by the default root object is not very
-   interesting, because the default root object has no children.  Its
+   uses the resource tree supplied by the default root resource is not very
+   interesting, because the default root resource has no children.  Its
    availability is more useful when you're developing an application using
    :term:`URL dispatch`.
 
@@ -235,7 +229,7 @@ There is only one difference between a *container* resource and a *leaf*
 resource: *container* resources possess a ``__getitem__`` method while *leaf*
 resources do not.  The ``__getitem__`` method was chosen as the signifying
 difference between the two types of resources because the presence of this
-method is how Python itself typically determines whether an object is
+method is how Python itself typically determines whether a resource is
 "containerish" or not.
 
 Each container resource is presumed to be willing to return a child resource
@@ -252,13 +246,13 @@ Usually, the traversal root is a *container* resource, and as such it
 contains other resources.  However, it doesn't *need* to be a container.
 Your resource tree can be as shallow or as deep as you require.
 
-In general, the resource tree is traversed beginning at its root object using
-a sequence of path elements described by the ``PATH_INFO`` of the current
-request; if there are path segments, the root object's ``__getitem__`` is
-called with the next path segment, and it is expected to return another
-resource object.  The resulting object's ``__getitem__`` is called with the
-very next path segment, and it is expected to return another resource object.
-This happens *ad infinitum* until all path segments are exhausted.
+In general, the resource tree is traversed beginning at its root resource
+using a sequence of path elements described by the ``PATH_INFO`` of the
+current request; if there are path segments, the root resource's
+``__getitem__`` is called with the next path segment, and it is expected to
+return another resource.  The resulting resource's ``__getitem__`` is called
+with the very next path segment, and it is expected to return another
+resource.  This happens *ad infinitum* until all path segments are exhausted.
 
 .. index::
    single: traversal algorithm
@@ -307,7 +301,7 @@ and a :term:`view name`.
     environment.
 
 #.  The :term:`root factory` is called with the :term:`request`.  It
-    returns a :term:`root` object.
+    returns a :term:`root` resource.
 
 #.  The router uses the WSGI environment's ``PATH_INFO`` information
     to determine the path segments to traverse.  The leading slash is
@@ -327,15 +321,15 @@ and a :term:`view name`.
     Thus, a request with a ``PATH_INFO`` variable of ``/a/b/c`` maps
     to the traversal sequence ``[u'a', u'b', u'c']``.
 
-#.  :term:`Traversal` begins at the root object returned by the root
-    factory.  For the traversal sequence ``[u'a', u'b', u'c']``, the
-    root object's ``__getitem__`` is called with the name ``a``.
-    Traversal continues through the sequence.  In our example, if the
-    root object's ``__getitem__`` called with the name ``a`` returns
-    an object (aka "object ``a``"), that object's ``__getitem__`` is
-    called with the name ``b``.  If object A returns an object when
-    asked for ``b``, "object ``b``"'s ``__getitem__`` is then asked
-    for the name ``c``, and may return "object ``c``".
+#.  :term:`Traversal` begins at the root resource returned by the root
+    factory.  For the traversal sequence ``[u'a', u'b', u'c']``, the root
+    resource's ``__getitem__`` is called with the name ``a``.  Traversal
+    continues through the sequence.  In our example, if the root resource's
+    ``__getitem__`` called with the name ``a`` returns a resource (aka
+    "resource ``a``"), that resource's ``__getitem__`` is called with the name
+    ``b``.  If resource A returns a resource when asked for ``b``, "resource
+    ``b``"'s ``__getitem__`` is then asked for the name ``c``, and may return
+    "resource ``c``".
 
 #.  Traversal ends when a) the entire path is exhausted or b) when any
     resouce raises a :exc:`KeyError` from its ``__getitem__`` or c) when any
@@ -345,7 +339,7 @@ and a :term:`view name`.
     following the ``@@`` token should be treated as a :term:`view name`).
 
 #.  When traversal ends for any of the reasons in the previous step,
-    the last object found during traversal is deemed to be the
+    the last resource found during traversal is deemed to be the
     :term:`context`.  If the path has been exhausted when traversal
     ends, the :term:`view name` is deemed to be the empty string
     (``''``).  However, if the path was *not* exhausted before
@@ -423,7 +417,7 @@ Here's what happens:
 The fact that it does not find "baz" at this point does not signify an
 error condition.  It signifies that:
 
-- the :term:`context` is "bar" (the context is the last item found
+- the :term:`context` is "bar" (the context is the last resource found
   during traversal).
 
 - the :term:`view name` is ``baz``
@@ -432,11 +426,11 @@ error condition.  It signifies that:
 
 At this point, traversal has ended, and :term:`view lookup` begins.
 
-Because it's the "context", the view lookup machinery examines "bar"
-to find out what "type" it is. Let's say it finds that the context is
-a ``Bar`` type (because "bar" happens to be an instance of the class
-``Bar``).  Using the :term:`view name` (``baz``) and the type, view
-lookup asks the :term:`application registry` this question:
+Because it's the "context" resource, the view lookup machinery examines "bar"
+to find out what "type" it is. Let's say it finds that the context is a
+``Bar`` type (because "bar" happens to be an instance of the class ``Bar``).
+Using the :term:`view name` (``baz``) and the type, view lookup asks the
+:term:`application registry` this question:
 
 - Please find me a :term:`view callable` registered using a
   :term:`view configuration` with the name "baz" that can be used for
@@ -477,7 +471,7 @@ The user asks for ``http://example.com/foo/bar/baz/biz/buz.txt``
 The fact that it does not find "buz.txt" at this point does not
 signify an error condition.  It signifies that:
 
-- the :term:`context` is "biz" (the context is the last item found
+- the :term:`context` is "biz" (the context is the last resource found
   during traversal).
 
 - the :term:`view name` is "buz.txt"
@@ -486,11 +480,11 @@ signify an error condition.  It signifies that:
 
 At this point, traversal has ended, and :term:`view lookup` begins.
 
-Because it's the "context", the view lookup machinery examines "biz"
-to find out what "type" it is. Let's say it finds that the context is
-a ``Biz`` type (because "biz" is an instance of the Python class
-``Biz``).  Using the :term:`view name` (``buz.txt``) and the type,
-view lookup asks the :term:`application registry` this question:
+Because it's the "context" resource, the view lookup machinery examines "biz"
+to find out what "type" it is. Let's say it finds that the context is a
+``Biz`` type (because "biz" is an instance of the Python class ``Biz``).
+Using the :term:`view name` (``buz.txt``) and the type, view lookup asks the
+:term:`application registry` this question:
 
 - Please find me a :term:`view callable` registered with a :term:`view
   configuration` with the name ``buz.txt`` that can be used for class
@@ -502,22 +496,21 @@ callable`.  The view callable is then called with the current
 :term:`WebOb` :term:`request` as the sole argument: ``request``; it is
 expected to return a response.
 
-.. sidebar:: The Example View Callables Accept Only a Request; How Do I Access the Context?
-
-   Most of the examples in this book assume that a view callable is
-   typically passed only a :term:`request` object.  Sometimes your
-   view callables need access to the :term:`context`, especially when
-   you use :term:`traversal`.  You might use a supported alternate
-   view callable argument list in your view callables such as the
-   ``(context, request)`` calling convention described in
-   :ref:`request_and_context_view_definitions`.  But you don't need to
-   if you don't want to.  In view callables that accept only a
-   request, the :term:`context` found by traversal is available as the
-   ``context`` attribute of the request object,
-   e.g. ``request.context``.  The :term:`view name` is available as
-   the ``view_name`` attribute of the request object,
-   e.g. ``request.view_name``.  Other :app:`Pyramid` -specific
-   request attributes are also available as described in
+.. sidebar:: The Example View Callables Accept Only a Request; How Do I Access the Context Resource?
+
+   Most of the examples in this book assume that a view callable is typically
+   passed only a :term:`request` object.  Sometimes your view callables need
+   access to the :term:`context` resource, especially when you use
+   :term:`traversal`.  You might use a supported alternate view callable
+   argument list in your view callables such as the ``(context, request)``
+   calling convention described in
+   :ref:`request_and_context_view_definitions`.  But you don't need to if you
+   don't want to.  In view callables that accept only a request, the
+   :term:`context` resource found by traversal is available as the
+   ``context`` attribute of the request object, e.g. ``request.context``.
+   The :term:`view name` is available as the ``view_name`` attribute of the
+   request object, e.g. ``request.view_name``.  Other :app:`Pyramid`
+   -specific request attributes are also available as described in
    :ref:`special_request_attributes`.
 
 References
@@ -534,5 +527,5 @@ deal with traversal, such as traversal invocation from within
 application code.
 
 The :func:`pyramid.url.resource_url` function generates a URL when
-given an object retrieved from an resource tree.
+given a resource retrieved from an resource tree.
 
diff --git a/docs/narr/urldispatch.rst b/docs/narr/urldispatch.rst
index 739a826c1..b7164ec40 100644
--- a/docs/narr/urldispatch.rst
+++ b/docs/narr/urldispatch.rst
@@ -6,33 +6,32 @@
 URL Dispatch
 ============
 
-The URL dispatch feature of :app:`Pyramid` allows you to either
-augment or replace :term:`traversal` as a :term:`context finding`
-mechanism, allowing URL pattern matching to have the "first crack" at
-resolving a given URL to :term:`context` and :term:`view name`.
+The URL dispatch feature of :app:`Pyramid` allows you to either augment or
+replace :term:`traversal` as a :term:`resource location` mechanism, allowing
+URL pattern matching to have the "first crack" at resolving a given URL to
+:term:`context` resource.
 
-Although it is a "context-finding" mechanism, ironically, using URL
-dispatch exclusively allows you to avoid thinking about your
-application in terms of "contexts" and "view names" entirely.
+Although it is a "resource-location" mechanism, ironically, using URL
+dispatch exclusively allows you to avoid thinking about your application in
+terms of resources entirely.
 
 Many applications don't need :app:`Pyramid` features -- such as
 context-sensitive declarative security via an :term:`authorization policy` --
-that benefit from having any visible separation between :term:`context
-finding` and :term:`view lookup`.  To this end, URL dispatch provides a handy
-syntax that allows you to effectively map URLs *directly* to :term:`view`
-code in such a way that you needn't think about your application in terms of
-"context finding" at all.  This makes developing a :app:`Pyramid` application
-seem more like developing an application in a system that is "context-free",
-such as :term:`Pylons` or :term:`Django`.
-
-Whether or not you care about "context", it often makes a lot of sense
-to use :term:`URL dispatch` instead of :term:`traversal` in an
-application that has no natural data hierarchy.  For instance, if all
-the data in your application lives in a relational database, and that
-relational database has no self-referencing tables that form a natural
-hierarchy, URL dispatch is easier to use than traversal, and is often
-a more natural fit for creating an application that manipulates "flat"
-data.
+that benefit from having any visible separation between :term:`resource
+location` and :term:`view lookup`.  To this end, URL dispatch provides a
+handy syntax that allows you to effectively map URLs *directly* to
+:term:`view` code in such a way that you needn't think about your application
+in terms of "resource location" at all.  This makes developing a
+:app:`Pyramid` application seem more like developing an application in a
+system that is "resource-free", such as :term:`Pylons` or :term:`Django`.
+
+Whether or not you care about "resources", it often makes a lot of sense to
+use :term:`URL dispatch` instead of :term:`traversal` in an application that
+has no natural data hierarchy.  For instance, if all the data in your
+application lives in a relational database, and that relational database has
+no self-referencing tables that form a natural hierarchy, URL dispatch is
+easier to use than traversal, and is often a more natural fit for creating an
+application that manipulates "flat" data.
 
 The presence of calls to the
 :meth:`pyramid.config.Configurator.add_route` method in imperative
@@ -47,22 +46,21 @@ dispatch`.
 High-Level Operational Overview
 -------------------------------
 
-If route configuration is present in an application, the
-:app:`Pyramid` :term:`Router` checks every incoming request against
-an ordered set of URL matching patterns present in a *route map*.
+If route configuration is present in an application, the :app:`Pyramid`
+:term:`Router` checks every incoming request against an ordered set of URL
+matching patterns present in a *route map*.
 
-If any route pattern matches the information in the :term:`request`
-provided to :app:`Pyramid`, a route-specific :term:`context` and
-:term:`view name` will be generated.  In this circumstance,
-:app:`Pyramid` will shortcut :term:`traversal`, and will invoke
-:term:`view lookup` using the context and view name generated by URL
-dispatch.  If the matched route names a :term:`view callable` in its
-configuration, that view callable will be invoked when view lookup is
-performed.
+If any route pattern matches the information in the :term:`request` provided
+to :app:`Pyramid`, a route-specific :term:`context` resource and :term:`view
+name` will be generated.  In this circumstance, :app:`Pyramid` will shortcut
+:term:`traversal`, and will invoke :term:`view lookup` using the context
+resource and view name generated by URL dispatch.  If the matched route names
+a :term:`view callable` in its configuration, that view callable will be
+invoked when view lookup is performed.
 
-However, if no route pattern matches the information in the
-:term:`request` provided to :app:`Pyramid`, it will fail over to
-using :term:`traversal` to perform context finding and view lookup.
+However, if no route pattern matches the information in the :term:`request`
+provided to :app:`Pyramid`, it will fail over to using :term:`traversal` to
+perform resource location and view lookup.
 
 Route Configuration
 -------------------
@@ -140,13 +138,12 @@ When a route configuration names a ``view`` attribute, the :term:`view
 callable` named as that ``view`` attribute will always be found and
 invoked when the associated route pattern matches during a request.
 
-The purpose of making it possible to specify a view callable within a
-route configuration is to prevent developers from needing to deeply
-understand the details of :term:`context finding` and :term:`view
-lookup`.  When a route names a view callable, and a request enters the
-system which matches the pattern of the route, the result is simple:
-the view callable associated with the route is invoked with the
-request that caused the invocation.
+The purpose of making it possible to specify a view callable within a route
+configuration is to prevent developers from needing to deeply understand the
+details of :term:`resource location` and :term:`view lookup`.  When a route
+names a view callable, and a request enters the system which matches the
+pattern of the route, the result is simple: the view callable associated with
+the route is invoked with the request that caused the invocation.
 
 For most usage, you needn't understand more than this; how it works is
 an implementation detail.  In the interest of completeness, however,
@@ -179,7 +176,7 @@ during a request.  To do so:
   to service requests that match the route pattern.
 
 In this way, we supply a shortcut to the developer.  Under the hood,
-the :term:`context finding` and :term:`view lookup` subsystems
+the :term:`resource location` and :term:`view lookup` subsystems
 provided by :app:`Pyramid` are still being utilized, but in a way
 which does not require a developer to understand either of them in
 detail.  It also means that we can allow a developer to combine
@@ -402,13 +399,12 @@ will never be evaluated.
 Route Factories
 ~~~~~~~~~~~~~~~
 
-A "route" configuration declaration can mention a "factory".  When
-that route matches a request, and a factory is attached to a route,
-the :term:`root factory` passed at startup time to the
-:term:`Configurator` is ignored; instead the factory associated with
-the route is used to generate a :term:`root` object.  This object will
-usually be used as the :term:`context` of the view callable ultimately
-found via :term:`view lookup`.
+A "route" configuration declaration can mention a "factory".  When that route
+matches a request, and a factory is attached to a route, the :term:`root
+factory` passed at startup time to the :term:`Configurator` is ignored;
+instead the factory associated with the route is used to generate a
+:term:`root` object.  This object will usually be used as the :term:`context`
+resource of the view callable ultimately found via :term:`view lookup`.
 
 .. code-block:: python
    :linenos:
@@ -419,17 +415,17 @@ found via :term:`view lookup`.
 The factory can either be a Python object or a :term:`dotted Python name` (a
 string) which points to such a Python object, as it is above.
 
-In this way, each route can use a different factory, making it
-possible to supply a different :term:`context` object to the view
-related to each particular route.
+In this way, each route can use a different factory, making it possible to
+supply a different :term:`context` resource object to the view related to
+each particular route.
 
-Supplying a different context for each route is useful when you're
-trying to use a :app:`Pyramid` :term:`authorization policy` to
-provide declarative, "context sensitive" security checks; each context
-can maintain a separate :term:`ACL`, as documented in
-:ref:`using_security_with_urldispatch`.  It is also useful when you
-wish to combine URL dispatch with :term:`traversal` as documented
-within :ref:`hybrid_chapter`.
+Supplying a different context resource for each route is useful when you're
+trying to use a :app:`Pyramid` :term:`authorization policy` to provide
+declarative, "context sensitive" security checks; each resource can maintain
+a separate :term:`ACL`, as documented in
+:ref:`using_security_with_urldispatch`.  It is also useful when you wish to
+combine URL dispatch with :term:`traversal` as documented within
+:ref:`hybrid_chapter`.
 
 Route Configuration Arguments
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -458,29 +454,28 @@ represent neither predicates nor view configuration information.
 ``factory``
   A Python object (often a function or a class) or a :term:`dotted
   Python name` to such an object that will generate a
-  :app:`Pyramid` :term:`context` object when this route
+  :app:`Pyramid` :term:`context` resource object when this route
   matches. For example, ``mypackage.resources.MyFactoryClass``.  If this
   argument is not specified, the traversal root factory will be used.
 
 ``traverse``
-  If you would like to cause the :term:`context` to be something other
-  than the :term:`root` object when this route matches, you can spell
-  a traversal pattern as the ``traverse`` argument.  This traversal
-  pattern will be used as the traversal path: traversal will begin at
-  the root object implied by this route (either the global root, or
-  the object returned by the ``factory`` associated with this route).
+  If you would like to cause the :term:`context` resource to be something
+  other than the :term:`root` resource object when this route matches, you
+  can spell a traversal pattern as the ``traverse`` argument.  This traversal
+  pattern will be used as the traversal path: traversal will begin at the
+  root object implied by this route (either the global root, or the object
+  returned by the ``factory`` associated with this route).
 
   The syntax of the ``traverse`` argument is the same as it is for
   ``pattern``. For example, if the ``pattern`` provided is
-  ``articles/{article}/edit``, and the ``traverse`` argument provided
-  is ``/{article}``, when a request comes in that causes the route to
-  match in such a way that the ``article`` match value is '1' (when
-  the request URI is ``/articles/1/edit``), the traversal path will be
-  generated as ``/1``.  This means that the root object's
-  ``__getitem__`` will be called with the name ``1`` during the
-  traversal phase.  If the ``1`` object exists, it will become the
-  :term:`context` of the request.  :ref:`traversal_chapter` has more
-  information about traversal.
+  ``articles/{article}/edit``, and the ``traverse`` argument provided is
+  ``/{article}``, when a request comes in that causes the route to match in
+  such a way that the ``article`` match value is '1' (when the request URI is
+  ``/articles/1/edit``), the traversal path will be generated as ``/1``.
+  This means that the root object's ``__getitem__`` will be called with the
+  name ``1`` during the traversal phase.  If the ``1`` object exists, it will
+  become the :term:`context` resource of the request.
+  :ref:`traversal_chapter` has more information about traversal.
 
   If the traversal path contains segment marker names which are not
   present in the ``pattern`` argument, a runtime error will occur.
@@ -576,7 +571,7 @@ represent neither predicates nor view configuration information.
   with predefined predicates as necessary.  Each custom predicate
   callable should accept two arguments: ``context`` and ``request``
   and should return either ``True`` or ``False`` after doing arbitrary
-  evaluation of the context and/or the request.  If all callables
+  evaluation of the context resource and/or the request.  If all callables
   return ``True``, the associated route will be considered viable for
   a given request.  If any custom predicate returns ``False``, route
   matching continues.  Note that the value ``context`` will always be
@@ -646,10 +641,9 @@ represent neither predicates nor view configuration information.
   effect.
 
 ``use_global_views``
-  When a request matches this route, and view lookup cannot find a view
-  which has a 'route_name' predicate argument that matches the route,
-  try to fall back to using a view that otherwise matches the context,
-  request, and view name (but does not match the route name predicate).
+  When a request matches this route, and view lookup cannot find a view which
+  has a 'route_name' predicate argument that matches the route, try to fall
+  back to using a view that otherwise matches the context and request.
 
 .. _custom_route_predicates:
 
@@ -798,13 +792,12 @@ request enters the system, for each route configuration declaration
 present in the system, :app:`Pyramid` checks the ``PATH_INFO``
 against the pattern declared.
 
-If any route matches, the route matching process stops.  The
-:term:`request` is decorated with a special :term:`interface` which
-describes it as a "route request", the :term:`context` and :term:`view
-name` are generated, and the context, the view name, and the resulting
-request are handed off to :term:`view lookup`.  This process is
-otherwise known as :term:`context finding`.  During view lookup, if
-any ``view`` argument was provided within the matched route
+If any route matches, the route matching process stops.  The :term:`request`
+is decorated with a special :term:`interface` which describes it as a "route
+request", the :term:`context` resource is generated, and the context, the
+view name, and the resulting request are handed off to :term:`view lookup`.
+This process is otherwise known as :term:`resource location`.  During view
+lookup, if any ``view`` argument was provided within the matched route
 configuration, the :term:`view callable` it points to is called.
 
 When a route configuration is declared, it may contain :term:`route
@@ -817,9 +810,9 @@ provided to a route configuration returns ``False``, that route is
 skipped and route matching continues through the ordered set of
 routes.
 
-If no route matches after all route patterns are exhausted,
-:app:`Pyramid` falls back to :term:`traversal` to do :term:`context
-finding` and :term:`view lookup`.
+If no route matches after all route patterns are exhausted, :app:`Pyramid`
+falls back to :term:`traversal` to do :term:`resource location` and
+:term:`view lookup`.
 
 .. index::
    single: matchdict
@@ -962,15 +955,16 @@ URL by the process will be passed to the view callable.
 Example 3
 ~~~~~~~~~
 
-The context object passed in to a view found as the result of URL dispatch
-will, by default, be an instance of the object returned by the :term:`root
-factory` configured at startup time (the ``root_factory`` argument to the
-:term:`Configurator` used to configure the application).
+The context resource object passed in to a view found as the result of URL
+dispatch will, by default, be an instance of the object returned by the
+:term:`root factory` configured at startup time (the ``root_factory``
+argument to the :term:`Configurator` used to configure the application).
 
 You can override this behavior by passing in a ``factory`` argument to the
-:meth:`pyramid.config.Configurator.add_route` method for a particular
-route.  The ``factory`` should be a callable that accepts a :term:`request`
-and returns an instance of a class that will be the context used by the view.
+:meth:`pyramid.config.Configurator.add_route` method for a particular route.
+The ``factory`` should be a callable that accepts a :term:`request` and
+returns an instance of a class that will be the context resource used by the
+view.
 
 An example of using a route with a factory:
 
@@ -981,9 +975,9 @@ An example of using a route with a factory:
                     view='myproject.views.idea_view',
                     factory='myproject.resources.Idea')
 
-The above route will manufacture an ``Idea`` resource as a
-:term:`context`, assuming that ``mypackage.resources.Idea`` resolves to a
-class that accepts a request in its ``__init__``.  For example:
+The above route will manufacture an ``Idea`` resource as a :term:`context`,
+assuming that ``mypackage.resources.Idea`` resolves to a class that accepts a
+request in its ``__init__``.  For example:
 
 .. code-block:: python
    :linenos:
@@ -1237,13 +1231,13 @@ Using :app:`Pyramid` Security With URL Dispatch
 --------------------------------------------------
 
 :app:`Pyramid` provides its own security framework which consults an
-:term:`authorization policy` before allowing any application code to
-be called.  This framework operates in terms of an access control
-list, which is stored as an ``__acl__`` attribute of a context object.
-A common thing to want to do is to attach an ``__acl__`` to the
-context object dynamically for declarative security purposes.  You can
-use the ``factory`` argument that points at a factory which attaches a
-custom ``__acl__`` to an object at its creation time.
+:term:`authorization policy` before allowing any application code to be
+called.  This framework operates in terms of an access control list, which is
+stored as an ``__acl__`` attribute of a resource object.  A common thing to
+want to do is to attach an ``__acl__`` to the resource object dynamically for
+declarative security purposes.  You can use the ``factory`` argument that
+points at a factory which attaches a custom ``__acl__`` to an object at its
+creation time.
 
 Such a ``factory`` might look like so:
 
@@ -1257,13 +1251,12 @@ Such a ``factory`` might look like so:
           if article == '1':
               self.__acl__ = [ (Allow, 'editor', 'view') ]
 
-If the route ``archives/{article}`` is matched, and the article number
-is ``1``, :app:`Pyramid` will generate an ``Article``
-:term:`context` with an ACL on it that allows the ``editor`` principal
-the ``view`` permission.  Obviously you can do more generic things
-than inspect the routes match dict to see if the ``article`` argument
-matches a particular string; our sample ``Article`` factory class is
-not very ambitious.
+If the route ``archives/{article}`` is matched, and the article number is
+``1``, :app:`Pyramid` will generate an ``Article`` :term:`context` resource
+with an ACL on it that allows the ``editor`` principal the ``view``
+permission.  Obviously you can do more generic things than inspect the routes
+match dict to see if the ``article`` argument matches a particular string;
+our sample ``Article`` factory class is not very ambitious.
 
 .. note:: See :ref:`security_chapter` for more information about
    :app:`Pyramid` security and ACLs.
diff --git a/docs/narr/views.rst b/docs/narr/views.rst
index cda6de48b..85bc8a5b0 100644
--- a/docs/narr/views.rst
+++ b/docs/narr/views.rst
@@ -17,17 +17,17 @@ request made to your application.
    that implements a view *callable*, and the process of view
    *lookup*.
 
-The chapter :ref:`contextfinding_chapter` describes how, using information
-from the :term:`request`, a :term:`context` and a :term:`view name` are
-computed.  But neither the context nor the view name found are very useful
-unless those elements can eventually be mapped to a :term:`view callable`.
-
-The job of actually locating and invoking the "best" :term:`view
-callable` is the job of the :term:`view lookup` subsystem.  The view
-lookup subsystem compares information supplied by :term:`context
-finding` against :term:`view configuration` statements made by the
-developer stored in the :term:`application registry` to choose the
-most appropriate view callable for a specific request.
+The chapter :ref:`resourcelocation_chapter` describes how, using information
+from the :term:`request`, a :term:`context` resource is computed.  But the
+context resource found isn't very useful unless those elements can eventually
+be mapped to a :term:`view callable`.
+
+The job of actually locating and invoking the "best" :term:`view callable` is
+the job of the :term:`view lookup` subsystem.  The view lookup subsystem
+compares information supplied by :term:`resource location` against
+:term:`view configuration` statements made by the developer stored in the
+:term:`application registry` to choose the most appropriate view callable for
+a specific request.
 
 This chapter provides documentation detailing the process of creating
 view callables, documentation about performing view configuration, and
@@ -130,7 +130,7 @@ represent the method expected to return a response, you can use an
 	Usually, view callables are defined to accept only a single argument:
 	``request``.  However, view callables may alternately be defined as
 	classes, functions, or any callable that accept *two* positional
-	arguments: a :term:`context` as the first argument and a
+	arguments: a :term:`context` resource as the first argument and a
 	:term:`request` as the second argument.
 
 	The :term:`context` and :term:`request` arguments passed to a view
@@ -523,9 +523,9 @@ inserted into the set of keyword arguments passed to the template as the
 will be an instance of that class.  Also inserted into the keywords passed to
 the template are ``renderer_name`` (the string used in the ``renderer``
 attribute of the directive), ``renderer_info`` (an object containing
-renderer-related information), ``context`` (the context of the view used to
-render the template), and ``request`` (the request passed to the view used to
-render the template).
+renderer-related information), ``context`` (the context resource of the view
+used to render the template), and ``request`` (the request passed to the view
+used to render the template).
 
 Here's an example view configuration which uses a Chameleon ZPT
 renderer:
@@ -982,12 +982,11 @@ exception views which have a name will be ignored.
 
 .. note::
 
-  Normal (i.e., non-exception) views registered against a context which
-  inherits from :exc:`Exception` will work normally.  When an
-  exception view configuration is processed, *two* views are
-  registered.  One as a "normal" view, the other as an "exception"
-  view.  This means that you can use an exception as ``context`` for a
-  normal view.
+  Normal (i.e., non-exception) views registered against a context resource
+  type which inherits from :exc:`Exception` will work normally.  When an
+  exception view configuration is processed, *two* views are registered.  One
+  as a "normal" view, the other as an "exception" view.  This means that you
+  can use an exception as ``context`` for a normal view.
 
 Exception views can be configured with any view registration mechanism:
 ``@view_config`` decorator, ZCML, or imperative ``add_view`` styles.
@@ -1120,8 +1119,8 @@ response object, you will need to ensure you do this yourself.
 
 .. _view_configuration:
 
-View Configuration: Mapping a Context to a View
------------------------------------------------
+View Configuration: Mapping a Resource Type to a View
+-----------------------------------------------------
 
 A developer makes a :term:`view callable` available for use within a
 :app:`Pyramid` application via :term:`view configuration`.  A view
@@ -1129,10 +1128,8 @@ configuration associates a view callable with a set of statements
 that determine the set of circumstances which must be true for the view
 callable to be invoked.
 
-A view configuration statement is made about information present in
-the :term:`context` and in the :term:`request`, as well as the
-:term:`view name`.  These three pieces of information are known,
-collectively, as a :term:`triad`.
+A view configuration statement is made about information present in the
+:term:`context` resource and the :term:`request`.
 
 View configuration is performed in one of these ways:
 
@@ -1269,11 +1266,11 @@ the usage of the configured view.
 
 ``context``
   An object representing a Python class that the :term:`context` resource
-  must be an instance of, *or* the :term:`interface` that the :term:`context`
+  must be an instance of *or* the :term:`interface` that the :term:`context`
   must provide in order for this view to be found and called.  This predicate
-  is true when the :term:`context` is an instance of the represented class or
-  if the :term:`context` provides the represented interface; it is otherwise
-  false.
+  is true when the :term:`context` resource is an instance of the represented 
+  class or if the :term:`context` provides the represented interface; it is 
+  otherwise false.
 
   If ``context`` is not supplied, the value ``None``, which matches any
   resource, is used.
@@ -1290,10 +1287,10 @@ the usage of the configured view.
   will be used by :term:`traversal` against the result of the route's
   :term:`root factory`.
 
-  If ``route_name`` is not supplied, the view callable will be have a
-  chance of being invoked if no other route was matched. This is when
-  the request object of the :term:`triad` does not indicate it matched
-  any configured route.
+  If ``route_name`` is not supplied, the view callable will be have a chance
+  of being invoked if no other route was matched. This is when the
+  request/context pair found via :term:`resource location` does not indicate
+  it matched any configured route.
 
 ``request_type``
   This value should be an :term:`interface` that the :term:`request`
@@ -1334,7 +1331,7 @@ the usage of the configured view.
 
 ``containment``
   This value should be a reference to a Python class or
-  :term:`interface` that a parent object in the context's
+  :term:`interface` that a parent object in the context resource's
   :term:`lineage` must provide in order for this view to be found and
   called.  The resources in your resource tree must be "location-aware" to
   use this feature.
@@ -1414,7 +1411,7 @@ the usage of the configured view.
   predicates can be combined with predefined predicates as necessary.
   Each custom predicate callable should accept two arguments:
   ``context`` and ``request`` and should return either ``True`` or
-  ``False`` after doing arbitrary evaluation of the context and/or the
+  ``False`` after doing arbitrary evaluation of the context resource and/or the
   request.  If all callables return ``True``, the associated view
   callable will be considered viable for a given request.
 
@@ -1785,9 +1782,9 @@ Configuring View Security
 If an :term:`authorization policy` is active, any :term:`permission` attached
 to a :term:`view configuration` found during view lookup will be verified.
 This will ensure that the currently authenticated user possesses that
-permission against the :term:`context` before the view function is actually
-called.  Here's an example of specifying a permission in a view configuration
-using :meth:`pyramid.config.Configurator.add_view`:
+permission against the :term:`context` resource before the view function is
+actually called.  Here's an example of specifying a permission in a view
+configuration using :meth:`pyramid.config.Configurator.add_view`:
 
 .. code-block:: python
    :linenos:
@@ -1811,16 +1808,14 @@ returned to the client as per :ref:`protecting_views`.
 View Lookup and Invocation
 --------------------------
 
-:term:`View lookup` is the :app:`Pyramid` subsystem responsible for
-finding an invoking a :term:`view callable`.  The view lookup
-subsystem is passed a :term:`context`, a :term:`view name`, and the
-:term:`request` object.  These three bits of information are referred
-to within this chapter as the :term:`triad`.
+:term:`View lookup` is the :app:`Pyramid` subsystem responsible for finding
+an invoking a :term:`view callable`.  The view lookup subsystem is passed a
+:term:`context` and a:term:`request` object.
 
 :term:`View configuration` information stored within in the
-:term:`application registry` is compared against a triad by the view
-lookup subsystem in order to find the "best" view callable for the set
-of circumstances implied by the triad.
+:term:`application registry` is compared against the context and request by
+the view lookup subsystem in order to find the "best" view callable for the
+set of circumstances implied by the context and request.
 
 Predicate attributes of view configuration can be thought of like
 "narrowers".  In general, the greater number of predicate attributes