Adds server options hash example to Readme.md

And fixes typos in CONTRIBUTING.md

CONTRIBUTING.md

@@ -15,17 +15,17 @@ Because SOAP Web Services can differ amongst implementations, there is high risk
 * Pull Requests **must have accompanying tests** (either Unit or Request/Response Sample tests are welcome). Your chances of getting the PR merged are very low if you don't provide any tests.
 * Pull Requests must have passing travis builds.
 * Pull Requests must be able to merge automatically from github.
-* Please **do not close a pull request due to a request to rebase**.  Git is a powerful VCS and deserves your time in learning how to rebase properly.  Pull Requests are updated automatically on github when you force push to your branch after rebasing. 
+* Please **do not close a pull request due to a request to rebase**.  Git is a powerful VCS and deserves your time in learning how to rebase properly.  Pull Requests are updated automatically on github when you force push to your branch after rebasing.
 
-Very useful articles/help on this topic: 
-  - [GitHub Help - About Git rebase](https://help.github.com/articles/about-git-rebase/) 
+Very useful articles/help on this topic:
+  - [GitHub Help - About Git rebase](https://help.github.com/articles/about-git-rebase/)
   - [GitHub Help - Using Git rebase](https://help.github.com/articles/using-git-rebase/)
 
-* Please use descriptive commit messages.  Commit messages are used during the creation of history and release notes.  You'll make the job of maintaners much easier by doing this.
+* Please use descriptive commit messages.  Commit messages are used during the creation of history and release notes.  You'll make the job of maintainers much easier by doing this.
 
 ##Making Changes
 * Any and all pull requests to change documentation or typos are welcome!
-* Any WSDL checked in should be as small and as generic as possible.  This is to keep the size of the codebase from growing too large and to keep the reason for submitting the WSDL clear I.E. if the WSDL was submitted because attributes were not being parsed on response XML, then it would be appropriate to submit a WSDL that defines a response with attributes *and nothing else*.  If you find an issue with the parser not being able to handle large WSDLs, then it would be approprate to sumbit a large WSDL to recreate the issue with.
+* Any WSDL checked in should be as small and as generic as possible.  This is to keep the size of the codebase from growing too large and to keep the reason for submitting the WSDL clear I.E. if the WSDL was submitted because attributes were not being parsed on response XML, then it would be appropriate to submit a WSDL that defines a response with attributes *and nothing else*.  If you find an issue with the parser not being able to handle large WSDLs, then it would be appropriate to submit a large WSDL to recreate the issue with.
 * If your issue is WSDL related:
 ````
     1. Make your WSDL as generic as possible to recreate the issue
@@ -36,7 +36,7 @@ Very useful articles/help on this topic:
 
 * If your issue is client related:
 ````
-    1. Capture the request / response XMl via client.lastRequest and client.lastResponse as well as the WSDL.
+    1. Capture the request / response XML via client.lastRequest and client.lastResponse as well as the WSDL.
     2. Make the WSDL, request, and response XML as generic as possible.
     3. Only include the messages or operations that are having issues.
     4. Add the appropriate files to test/request-response-samples (see the README therein)
@@ -52,7 +52,7 @@ Very useful articles/help on this topic:
 ````
 
 ##Issue Expiration
-Any pull request or issue filed is subject to an expiration date.  We will close any open issue that has not recieved a response within a 2 week timeframe.  The goal is not to sweep dirt under the rug, but to keep the focus on merging in pull requests.  Please provide pull requests that meet the above criteria wherever possible.
+Any pull request or issue filed is subject to an expiration date.  We will close any open issue that has not received a response within a 2 week timeframe.  The goal is not to sweep dirt under the rug, but to keep the focus on merging in pull requests.  Please provide pull requests that meet the above criteria wherever possible.
 
 ##Other ways you can contribute
 Please add response, request, and WSDL files to test/wsdl, and test/request-response-samples (see README therein).  Doing so documents behavior and reduces the likelihood that bugs will be introduced by future pull requests.

Readme.md

@@ -100,6 +100,26 @@ The `options` argument allows you to customize the client with the following pro
   soap.listen(server, '/wsdl', myService, xml);
 ```
 
+### Options
+You can pass in server and [WSDL Options](#handling-xml-attributes-value-and-xml-wsdloptions)
+using an options hash.
+
+``` javascript
+var xml = require('fs').readFileSync('myservice.wsdl', 'utf8');
+
+soap.listen(server, {
+    // Server options.
+    path: '/wsdl',
+    services: myService,
+    xml: xml,
+
+    // WSDL options.
+    attributesKey: 'theAttrs',
+    valueKey: 'theVal',
+    xmlKey: 'theXml'
+});
+```
+
 ### Server Logging
 
 If the `log` method is defined it will be called with 'received' and 'replied'