Doc fixes.

README.rst

@@ -68,7 +68,7 @@ You should read the source of myapp, after all it is your application.  A good p
 Another example
 ---------------
 
-Ptah101 scaffold generates a simple application which has an example form, view, a model called Link.  Ptah101 is meant to get your feet wet.  There is a more sophiticated example in the Ptah301 scaffold.  If you have not written a Pyramid application and/or you are not familiar with traversal do not attempt to use Ptah301.  
+Ptah101 scaffold generates a simple application which has an example form, view, a model called Link.  Ptah101 is meant to get your feet wet.  There is a more sophisticated example in the Ptah301 scaffold.  If you have not written a Pyramid application and/or you are not familiar with traversal do not attempt to use Ptah301.  
 
 Let's uninstall the ptah101 egg, myapp::
 

docs/startup.rst

@@ -52,17 +52,17 @@ Optional. If you are using ptah.make_wsgi_app some extra features are available:
 
 This function returns a WSGIApp.
 
-I have 2 ways to do register?
+I have 2 ways to do registration?
 -----------------------------
 Yes.  But its easier to think about it this way.  Pyramid is a agnostic 
 web framework.  Ptah is a application/web framework with opinions. 
 Ptah registration revolve around services (uri resolvers, models and a
 type system).  These ptah registration's are application specific and
-have no such equivilent in Pyramid (nor should they).  
+have no such equivalent in Pyramid (nor should they).  
 
 Where is ptah.config used?
 --------------------------
-Everywhere.  But you never touch it.  There is always formal API that is defined and (will be( documented.  The internal implementation uses ptah.config implementation.
+Everywhere.  But you never touch it.  There is always formal API that is defined and will be documented.  The internal implementation uses ptah.config implementation.
 
 Some examples:
 
@@ -113,7 +113,7 @@ Currently ptah differs in Pyramid in the following ways.
 
     - config statements do not have context (but will in 1.4?)
 
-    - config statemetns talk about concrete services of *pyramid* ala
+    - config statements talk about concrete services of *pyramid* ala
       route, views, etc. not high-level application services such as
       model registration.
 
@@ -123,10 +123,10 @@ Currently ptah differs in Pyramid in the following ways.
 
 In ptah there is a 
 more formal 2 stage configuration, registration stage and apply stage.
-It loads all packages and can be introspected and then a applying
+It loads all packages and can be introspected and then applys
 the configuration to the environment.  Why?  An example:
 
-URI implementaiton is a dictionary which maps the uri scheme / key
+URI implementation is a dictionary which maps the uri scheme / key
 to resolver callable.  {'crowd+user':ptah.crowd.userProvider}.  If an
 add-on package defines an additional URI resolver, what will happen when
 we load the external package:
@@ -147,10 +147,10 @@ we load the external package:
 
     - Another possibility is unloading this configuration.  In future we may have a add-on ecosystem where you will want to "unload" registrations.  
 
-  - registeration/apply are runtime features of ptah.config and maybe in future there will be remove registrations.  
+  - registration/apply are runtime features of ptah.config and maybe in future there will be remove registrations.  
 
 More thoughts
 -------------
-Pyramid is explicit. ptah is sort-of implicit and has indirection.  For instance ptah needs to scan packages with the entry-point ptah.  Pyramid would need to expose this functionality for ptah to plugin its own higher-level registration calls (uri, type system, etc).
-Also Ptah/ptah reuse ptah.config in a lot of places.  The pattern
-of having an public API which advertises the functionality but internally uses the ptah.config implementation - is inspired from Pyramid.
+Pyramid is explicit. Ptah is sort-of implicit and has indirection.  For instance Ptah needs to scan packages with the entry-point ptah.  Pyramid would need to expose this functionality for Ptah to plugin its own higher-level registration calls (uri, type system, etc).
+Also Ptah/ptah reuses ptah.config in a lot of places.  The pattern
+of having a public API which advertises the functionality but internally uses the ptah.config implementation - is inspired from Pyramid.

docs/tutorial.rst

@@ -4,7 +4,7 @@ Ptah Walkthrough
 
 You should have virtualenv with ptah installed.  Let's create an add-on::
 
-  ~/venv/src$ ../bin/paster create -t ptahdemo mypkg
+  ~/venv/src$ ../bin/paster create -t ptah101 mypkg
   ~/venv/src$ cd mypkg
   ~/venv/src/mypkg$ ../../bin/python setup.py develop
 

docs/unique.rst

@@ -96,7 +96,7 @@ it is flat.  We have 2 attributes we use for mapping on to heirarchies:
 ptah_cms_nodes.parent_uri and the ptah_cms_content.path columns.  The path
 attribute is how we efficiently do fast look ups.  Walking parent/children 
 relationships in a RDBMS is inefficient, say, compared to graph databases such
-as ZODB or Neo4J. RDBMS arent graphs.  The REST API is another example of this
+as ZODB or Neo4J. RDBMS aren't graphs.  The REST API is another example of this
 mantra.
 
 REST as First Class Citizen