From 38a43bcc650525f719519b90303f1278abbe4801 Mon Sep 17 00:00:00 2001
From: Jeffrey Phillips Freeman <jeffrey.freeman@syncleus.com>
Date: Sun, 1 Oct 2017 19:14:44 -0500
Subject: [PATCH] Deployed 2a216bd with MkDocs version: 0.16.3

---
 annotations/overview/index.html | 6 +++---
 mkdocs/search_index.json        | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/annotations/overview/index.html b/annotations/overview/index.html
index e6fac411..f608f25f 100644
--- a/annotations/overview/index.html
+++ b/annotations/overview/index.html
@@ -424,9 +424,9 @@ signature. Therefore an annotated method will behave differently if it's return
 name were to change. It is important to note that when a method is explicitly defined (doesnt use an annotation) then
 the method signature can be anything.</p>
 <p>Method names that are annotated must have one of the following prefixes: add, get, remove, set, is. Exactly which 
-prefixes are varies from one annotation to the next so see the annotations detailed documentation to make that
-determination. It is also possible to override this behavior by setting the operation argument availible on most
-annotations which defaults to <code class="codehilite">AUTO</code> when not specified.</p>
+prefixes are allowed varies from one annotation to the next so see the annotation's detailed documentation to make that
+determination. It is also possible to override this behavior by setting the <code class="codehilite">operation</code> argument available on most
+annotations which defaults to <code class="codehilite">AUTO</code>.</p>
                 
                   
                 
diff --git a/mkdocs/search_index.json b/mkdocs/search_index.json
index 7f14db1a..b9b2039c 100644
--- a/mkdocs/search_index.json
+++ b/mkdocs/search_index.json
@@ -97,7 +97,7 @@
         }, 
         {
             "location": "/annotations/overview/", 
-            "text": "The Ferma schema is defined by a collection of interfaces and classes written by the user. Each method will interact\nwith the underlying graph to either modify the graph in some way, or to retrieve an element or property from the graph.\nThere are two techniques for defining how these methods behave. Either you can explicitly implement the method, or you\ncan leave the method as abstract and annotate the method in order to allow Ferma to implement the method for you. Here\nwe will define the annotations available to you and how they work, along with a few examples.\n\n\nThe behavior of an annotated method is dictated not only by the annotation applied to it but also the method's\nsignature. Therefore an annotated method will behave differently if it's return type, arguments, or even if the method\nname were to change. It is important to note that when a method is explicitly defined (doesnt use an annotation) then\nthe method signature can be anything.\n\n\nMethod names that are annotated must have one of the following prefixes: add, get, remove, set, is. Exactly which \nprefixes are varies from one annotation to the next so see the annotations detailed documentation to make that\ndetermination. It is also possible to override this behavior by setting the operation argument availible on most\nannotations which defaults to \nAUTO\n when not specified.", 
+            "text": "The Ferma schema is defined by a collection of interfaces and classes written by the user. Each method will interact\nwith the underlying graph to either modify the graph in some way, or to retrieve an element or property from the graph.\nThere are two techniques for defining how these methods behave. Either you can explicitly implement the method, or you\ncan leave the method as abstract and annotate the method in order to allow Ferma to implement the method for you. Here\nwe will define the annotations available to you and how they work, along with a few examples.\n\n\nThe behavior of an annotated method is dictated not only by the annotation applied to it but also the method's\nsignature. Therefore an annotated method will behave differently if it's return type, arguments, or even if the method\nname were to change. It is important to note that when a method is explicitly defined (doesnt use an annotation) then\nthe method signature can be anything.\n\n\nMethod names that are annotated must have one of the following prefixes: add, get, remove, set, is. Exactly which \nprefixes are allowed varies from one annotation to the next so see the annotation's detailed documentation to make that\ndetermination. It is also possible to override this behavior by setting the \noperation\n argument available on most\nannotations which defaults to \nAUTO\n.", 
             "title": "Overview"
         }, 
         {
-- 
GitLab