Merge pull request #552 from w3c/kc-typos

Typos only - minor

conneg-by-ap/index.html

@@ -72,7 +72,7 @@ <h3>Compliance with this Document</h3>
         For the purpose of compliance, the normative sections of this document are
         <a href="#definitions">Section 2</a>,
         <a href="#abstractmodel">Section 5</a>,
-        <a href="#realisations">Section 6</a>, and
+        <a href="#realizations">Section 6</a>, and
         <a href="#testsuites">Section 7</a>.
       </p>
     </section>
@@ -213,7 +213,7 @@ <h3>Context</h3>
         agents might negotiate for content. These aspects are to be treated independently so content negotiation for a 
         resource involving negotiation by profile and potentially multiple other aspects of a resource will not affect
         each other. For this reason, other than a directive to maintain independence, no further discussion of 
-        negotiation by profile and this relations to other forms of negotiation are given. Specific realizations might
+        negotiation by profile and the relations to other forms of negotiation are given. Specific realizations might
         require special handling of profile and other forms of negotiation.
       </p>
       <p>
@@ -247,7 +247,7 @@ <h3>Requests and Responses</h3>
         </li>
       </ol>
       <p>
-        A third <em>request</em> type is given that is expected not to apply to all realisations of this abstract model
+        A third <em>request</em> type is given that is expected not to apply to all realizations of this abstract model
         and not all clients adhering to this specification need implement it.
       </p>
       <ol start="3">
@@ -331,12 +331,12 @@ <h4>list profiles tokens</h4>
         <p>
           A <em>server</em> responding to a <strong>list profiles tokens</strong> <em>request</em> MUST provide
           token/URI mappings that list tokens and URIs, either of which can be used for <strong>get resource by
-          profile</strong> <em>requests</em> within the same realisation.
+          profile</strong> <em>requests</em> within the same realization.
         </p>
       </section>
     </section>
   </section>
-  <section id="realisations">
+  <section id="realizations">
     <h2>Realizations</h2>
     <p>
       This section describes <em>realization</em>s of the abstract model in multiple implementation domains.
@@ -458,7 +458,7 @@ <h3>get resource by profile</h3>
         </pre>
         <p>
           Having performed content negotiation and returning a resource representation, it is RECOMMENDED
-          that the server also includes a Link header indicating the availability of alternate resources
+          that the server also include a Link header indicating the availability of alternate resources
           encoded in other media types and conforming to other profiles, as described above.
         </p>
       </section>
@@ -508,17 +508,17 @@ <h2>Query String Arguments</h2>
           un-sustainable in the long-term, given the likely numbers of profiles to be established.
         </p>
         <p>
-          For this reason, the QSA realisation allows either URIs or tokens for profiles to be used and it is expected,
-          though not mandated here, that QSA realisations will also allow URIs or tokens for Media Types and other
+          For this reason, the QSA realization allows either URIs or tokens for profiles to be used and it is expected,
+          though not mandated here, that QSA realizations will also allow URIs or tokens for Media Types and other
           content negotiation dimensions, such as language. There are already several initiatives that have created URIs
           for Media Types based on the IANA register's tokens.
         </p>
       </div>
       <p><strong><em>Resource URI</em></strong></p>
       <p>
         Resource URIs for which QSA-based profile negotiation is taking place MUST NOT themselves be QSA values
-        of other resource URIs in any QSA-based realisation. Such mechanics may be used but must be transparent to the
-        realisation's <em>client</em> applications.
+        of other resource URIs in any QSA-based realization. Such mechanics may be used but must be transparent to the
+        realization's <em>client</em> applications.
       </p>
       <pre class="example nohighlight" aria-busy="false" aria-live="polite" title="Resource URIs must not, themselves, be parameters of other URIs">
 For the representation of Resource X, according to Profile Y, in Media Type Z:
@@ -605,7 +605,7 @@ <h4>list profiles tokens</h4>
   <section id="testsuites">
     <h2>Test Suites</h2>
     <p>
-      This section includes links to software tools to be used for testing the adherence of implementations to the realisations
+      This section includes links to software tools to be used for testing the adherence of implementations to the realizations
       given in this document.
     </p>
     <dl>