Typo "dictate situatins" => "dictate situations" (#414)

ajs6f · iherman · commit 41e28b8aac23 · 2017-02-20T09:17:56.000+01:00
diff --git a/protocol/wd/index-respec.html b/protocol/wd/index-respec.html
@@ -827,7 +827,7 @@ <h3>Update an Existing Annotation</h3>
 <p>Annotations can be updated by using a PUT request to replace the entire state of the Annotation.  Annotation Servers SHOULD support this method. Servers MAY also support using a PATCH request to update only the aspects of the Annotation that have changed, but that functionality is not specified in this document.
 </p>
 
-<p>Replacing the Annotation with a new state MUST be done with the PUT method, where the body of the request is the intended new state of the Annotation.  The client SHOULD use the <code>If-Match</code> header with a value of the ETag it received from the server before the editing process began, to avoid collisions of multiple users modifying the same Annotation at the same time.  This feature is not mandatory to support, as not every system will have multiple users with the potential to change a single Annotation, or use cases might dictate situatins in which overwriting is the desired behavior.</p>
+<p>Replacing the Annotation with a new state MUST be done with the PUT method, where the body of the request is the intended new state of the Annotation.  The client SHOULD use the <code>If-Match</code> header with a value of the ETag it received from the server before the editing process began, to avoid collisions of multiple users modifying the same Annotation at the same time.  This feature is not mandatory to support, as not every system will have multiple users with the potential to change a single Annotation, or use cases might dictate situations in which overwriting is the desired behavior.</p>
 
 <p>Servers SHOULD reject update requests that modify the values of the <code>canonical</code> or <code>via</code> properties, if they have been already set, unless business logic allows the request to be trusted as authoritatively correctly a previous error.</p>
 

-Original file line number
+Diff line change
 <p>Annotations can be updated by using a PUT request to replace the entire state of the Annotation.  Annotation Servers SHOULD support this method. Servers MAY also support using a PATCH request to update only the aspects of the Annotation that have changed, but that functionality is not specified in this document.
 p>
 -<p>Replacing the Annotation with a new state MUST be done with the PUT method, where the body of the request is the intended new state of the Annotation.  The client SHOULD use the <code>If-Matchcode> header with a value of the ETag it received from the server before the editing process began, to avoid collisions of multiple users modifying the same Annotation at the same time.  This feature is not mandatory to support, as not every system will have multiple users with the potential to change a single Annotation, or use cases might dictate situatins in which overwriting is the desired behavior.p>
 +<p>Replacing the Annotation with a new state MUST be done with the PUT method, where the body of the request is the intended new state of the Annotation.  The client SHOULD use the <code>If-Matchcode> header with a value of the ETag it received from the server before the editing process began, to avoid collisions of multiple users modifying the same Annotation at the same time.  This feature is not mandatory to support, as not every system will have multiple users with the potential to change a single Annotation, or use cases might dictate situations in which overwriting is the desired behavior.p>
 <p>Servers SHOULD reject update requests that modify the values of the <code>canonicalcode> or <code>viacode> properties, if they have been already set, unless business logic allows the request to be trusted as authoritatively correctly a previous error.p>