Fix invalid ReSpec linting errors.

Author: msporny

index.html

@@ -27,7 +27,7 @@
         //subtitle: "Expressing information with verifiable provenance",
 
         // if you wish the publication date to be other than today, set this
-        publishDate: "2021-11-09",
+        publishDate: "2022-03-03",
         //crEnd: "2019-08-21",
         //prEnd: "2019-10-01",
         implementationReportURI: "https://w3c.github.io/vc-test-suite/implementations/",
@@ -552,9 +552,10 @@ <h3>Use Cases and Requirements</h3>
         </p>
 
         <p>
-A <dfn>conforming processor</dfn> is any algorithm realized as software and/or
-hardware that generates or consumes a <a>conforming document</a>. Conforming
-processors MUST produce errors when non-conforming documents are consumed.
+A <dfn class="lint-ignore">conforming processor</dfn> is any algorithm realized
+as software and/or hardware that generates or consumes a <a>conforming
+document</a>. Conforming processors MUST produce errors when non-conforming
+documents are consumed.
         </p>
 
         <p>
@@ -630,10 +631,10 @@ <h2>Core Data Model</h2>
         <h3>Claims</h3>
 
         <p>
-A <a>claim</a> is a statement about a <a>subject</a>. A <a>subject</a> is
-a thing about which <a>claims</a> can be made. <a>Claims</a> are expressed using
-<strong><em>subject</em></strong>-<dfn data-lt="property|properties">property</dfn>-<dfn>value</dfn>
-relationships.
+A <a>claim</a> is a statement about a <a>subject</a>. A <a>subject</a> is a
+thing about which <a>claims</a> can be made. <a>Claims</a> are expressed using
+<strong><em>subject</em></strong>-<dfn data-lt="property|properties">
+property</dfn>-<dfn class="lint-ignore">value</dfn> relationships.
         </p>
 
         <figure id="basic-structure">
@@ -1073,7 +1074,7 @@ <h3>Contexts</h3>
         </p>
 
         <dl>
-          <dt><dfn>@context</dfn></dt>
+          <dt><dfn class="lint-ignore">@context</dfn></dt>
           <dd>
 The value of the <code>@context</code> <a>property</a> MUST be an ordered set
 where the first item is a <a>URI</a> with the value
@@ -1193,7 +1194,7 @@ <h3>Identifiers</h3>
         </p>
 
         <dl>
-          <dt><dfn>id</dfn></dt>
+          <dt><dfn class="lint-ignore">id</dfn></dt>
           <dd>
 The value of the <code>id</code> <a>property</a> MUST be a single <a>URI</a>.
 It is RECOMMENDED that the <a>URI</a> in the <code>id</code> be one which, if
@@ -1700,11 +1701,12 @@ <h3>Proofs (Signatures)</h3>
 
         <p>
 This specification identifies two classes of proof mechanisms: external proofs
-and embedded proofs. An <dfn>external proof</dfn> is one that wraps an
-expression of this data model, such as a JSON Web Token, which is elaborated on
-in Section <a href="#json-web-token"></a>. An <dfn>embedded proof</dfn> is a
-mechanism where the proof is included in the data, such as a Linked Data
-Signature, which is elaborated upon in Section <a href="#data-integrity-proofs"></a>.
+and embedded proofs. An <dfn class="lint-ignore">external proof</dfn> is one
+that wraps an expression of this data model, such as a JSON Web Token, which is
+elaborated on in Section <a href="#json-web-token"></a>. An <dfn>embedded
+proof</dfn> is a mechanism where the proof is included in the data, such as a
+Linked Data Signature, which is elaborated upon in Section <a
+href="#data-integrity-proofs"></a>.
         </p>
 
         <p>
@@ -2064,18 +2066,19 @@ <h3>Lifecycle Details</h3>
 
         <ul>
           <li>
-An <a>issuer</a> <dfn data-lt="issue">issues</dfn> a
+An <a>issuer</a> <dfn class="lint-ignore" data-lt="issue">issues</dfn> a
 <a>verifiable credential</a> to a <a>holder</a>. Issuance always occurs before
 any other actions involving a <a>credential</a>.
           </li>
           <li>
-A <a>holder</a> might <dfn data-lt="transfers">transfer</dfn> one or more of
-its <a>verifiable credentials</a> to another <a>holder</a>.
+A <a>holder</a> might <dfn class="lint-ignore"
+data-lt="transfers">transfer</dfn> one or more of its <a>verifiable
+credentials</a> to another <a>holder</a>.
           </li>
           <li>
-A <a>holder</a> <dfn data-lt="present">presents</dfn> one or more of its
-<a>verifiable credentials</a> to a <a>verifier</a>, optionally inside a
-<a>verifiable presentation</a>.
+A <a>holder</a> <dfn class="lint-ignore" data-lt="present">presents</dfn> one or
+more of its <a>verifiable credentials</a> to a <a>verifier</a>, optionally
+inside a <a>verifiable presentation</a>.
           </li>
           <li>
 A <a>verifier</a> <a>verifies</a> the authenticity of the presented
@@ -2084,11 +2087,11 @@ <h3>Lifecycle Details</h3>
 of the <a>verifiable credentials</a>.
           </li>
          <li>
-An <a>issuer</a> might <dfn data-lt="revoke">revoke</dfn> a
+An <a>issuer</a> might <dfn class="lint-ignore" data-lt="revoke">revoke</dfn> a
 <a>verifiable credential</a>.
           </li>
           <li>
-A <a>holder</a> might <dfn data-lt="delete">delete</dfn> a
+A <a>holder</a> might <dfn class="lint-ignore" data-lt="delete">delete</dfn> a
 <a>verifiable credential</a>.
           </li>
         </ul>
@@ -2635,7 +2638,7 @@ <h3>Refreshing</h3>
 example, <code>ManualRefreshService2018</code>) and its <code>id</code>, which
 is the <a>URI</a> of the service. There is an expectation that machine readable
 information needs to be retrievable from the URI. The precise content of
-each refresh service is determined by the specific <code>refreshService</code> 
+each refresh service is determined by the specific <code>refreshService</code>
 <a>type</a> definition.
           </dd>
         </dl>
@@ -5520,7 +5523,7 @@ <h3>Differences between Contexts, Types, and CredentialSchemas</h3>
 properties, and cover some of the more specific use cases where it is possible
 to use these features of the data model.
         </p>
-        
+
         <p>
 The <code>type</code> property is used to uniquely identify
 the type of the <a>verifiable credential</a> in which it appears, i.e., to