Forgot to spell check

README.md

@@ -11,18 +11,18 @@ PseudoQL is a Pseudo-Query-Language.
 - Auto HAVING vs WHERE recognition w/ ability to force items into HAVING.
 
 ###Reasoning###
-One of the problems with SQL is that each database engine uses a slightly different version of SQL. For example, MySQL uses `` (backticks) to designate an identifier (table name, database name, column name, exc...) and SQL server uses [] (brackets) and PostgreSQL uses "" (double quotes). Although this is not a major issue to code around it, there are other situations which make moving from one database to another a very large hasstle like  the random (RAND(), RANDOM(), RND(), exc...) function; MySQL aliases RAND() and RANDOM() as the same function producing a number between 0 and 1 (with decimal), where PostgreSQL does not have RAND() function instead uses RANDOM() to do the same thing... However SQL server does not have RANDOM() function and instead uses RAND(). This kind of example can be quite difficult to code around because a "new" database engine may spawn and uses arguments in a different order or may not have the function at all and expect the user to do the grunt work to get the same results or the inverse may happen.
+One of the problems with SQL is that each database engine uses a slightly different version of SQL. For example, MySQL uses `` (back-ticks) to designate an identifier (table name, database name, column name, exc...) and SQL server uses [] (brackets) and PostgreSQL uses "" (double quotes). Although this is not a major issue to code around it, there are other situations which make moving from one database to another a very large hassle like  the random (RAND(), RANDOM(), RND(), exc...) function; MySQL aliases RAND() and RANDOM() as the same function producing a number between 0 and 1 (with decimal), where PostgreSQL does not have RAND() function instead uses RANDOM() to do the same thing... However SQL server does not have RANDOM() function and instead uses RAND(). This kind of example can be quite difficult to code around because a "new" database engine may spawn and uses arguments in a different order or may not have the function at all and expect the user to do the grunt work to get the same results or the inverse may happen.
 
-Security is also an issue. Although some database engines have "prepared-statments" it can be slow if many queries are being ran at once and some database engines do not support prepared-statments at all. This causes many developers to use libraries to escape their code for them or escape their code them selves which for novis developers can cause huge security holes.
+Security is also an issue. Although some database engines have "prepared-statements" it can be slow if many queries are being ran at once and some database engines do not support prepared-statements at all. This causes many developers to use libraries to escape their code for them or escape their code them selves which for novice developers can cause huge security holes.
 
 Since many modern developers develop using a "model" system (where each row of the database spawns a new object of a class representing the table from the database) this causes a few problems:
-- Each framework uses a different set of functions to query the database and developers often need to learn multiple ways of quering within the framework
+- Each framework uses a different set of functions to query the database and developers often need to learn multiple ways of querying within the framework
 - Frameworks can sometimes be limiting in what they allow you to query
 - Frameworks often require you to join tables yourself when the framework sometimes knows how tables relate
 - Frameworks offer little security limiting users (front end users) to only records they should have access to and expect the developer to limit every query them-selves when the entire application could know the limits
 
-###Model Limiting Rows Explination###
-Many companies have had security breaches due to non-conventional means of extracting data through the user interface undexpectidly. Assuming the developer(s) are extremely careful about sql injection volnerabilities this often is not the only way to extract information. For example, a user may do a request for a report from the server asking about a list of that user's orders and in the query may be asking to join on the users table (user that entered the order) and unless the developers were mindful the framework/controller may respond back with anything from password info/hash to that user's address/phone/ip/email information.
+###Model Limiting Rows Explanation###
+Many companies have had security breaches due to non-conventional means of extracting data through the user interface unexpectedly. Assuming the developer(s) are extremely careful about SQL injection vulnerabilities this often is not the only way to extract information. For example, a user may do a request for a report from the server asking about a list of that user's orders and in the query may be asking to join on the users table (user that entered the order) and unless the developers were mindful the framework/controller may respond back with anything from password info/hash to that user's address/phone/ip/email information.
 
 By running the framework through PQL first, the developer could configure the PQL parser to add additional restrictions on joins which should have very little impact on query speeds. For example:
 ```SQL