Update to ReSpec v3.3.4.

Author: msporny

index.html

@@ -11,7 +11,7 @@
     <script src='https://www.w3.org/Tools/respec/respec-w3c' class='remove'></script>
     <script src="./common.js" class="remove"></script>
     <script class="remove"
-      src="https://cdn.jsdelivr.net/gh/digitalbazaar/[email protected].3/dist/main.js"></script>
+      src="https://cdn.jsdelivr.net/gh/digitalbazaar/[email protected].4/dist/main.js"></script>
 
     <script class="remove">
       var respecConfig = {
@@ -376,7 +376,7 @@ <h3>What is a Verifiable Credential?</h3>
           </li>
           <li>
 Evidence demonstrating how the [=subject=] met the qualifications required
-for issuing the [=credential=] (for example, a measurement, proof of 
+for issuing the [=credential=] (for example, a measurement, proof of
 citizenship, or test result)
           </li>
           <li>
@@ -419,7 +419,7 @@ <h3>What is a Verifiable Credential?</h3>
         </p>
 
         <p>
-The word "verifiable" in the terms [=verifiable credential=] and 
+The word "verifiable" in the terms [=verifiable credential=] and
 [=verifiable presentation=] refers to the characteristic of a [=credential=]
 or [=presentation=] as being able to be [=verified=] by a [=verifier=],
 as defined in this document. Verifiability of a credential does not imply
@@ -506,12 +506,12 @@ <h3>Ecosystem Overview</h3>
         </p>
 
         <p>
-This ecosystem contrasts with the typical two-party or federated identity 
+This ecosystem contrasts with the typical two-party or federated identity
 provider models. An identity provider, sometimes abbreviated as <em>IdP</em>,
 is a system for creating, maintaining, and managing identity information for
 [=holders=] while providing authentication services to [=relying party=]
 applications within a federation or distributed network. In a federated
-identity model, the [=holder=] is tightly bound to the identity provider. 
+identity model, the [=holder=] is tightly bound to the identity provider.
 This specification avoids using "identity provider," "federated identity," or
 "relying party" terminology, except when comparing or mapping these concepts
 to other specifications. This specification decouples the identity provider
@@ -1016,7 +1016,7 @@ <h3>Presentations</h3>
 itself through [=presentation=] metadata.
 The [=verifiable presentation=] refers, via the `verifiableCredential` property,
 to a [=verifiable credential=].
-This [=credential=] is a self-contained [=verifiable credential graph=] 
+This [=credential=] is a self-contained [=verifiable credential graph=]
 containing [=credential=] metadata and other [=claims=]. This [=credential=]
 refers to a [=verifiable credential=] [=proof graph=] via a `proof` property,
 expressing the proof (usually a digital signature) of the [=credential=].
@@ -1043,7 +1043,7 @@ <h3>Presentations</h3>
 annotated to be a named graph instead of a default graph.
 The verifiable presentation proof graph has an object with 'Signature 8910'
 with 5 properties: 'type' with value 'DataIntegrityProof'; 'verificationMethod'
-with value 'Example Presenter Public Key 11'; 'created' with value 
+with value 'Example Presenter Public Key 11'; 'created' with value
 '2018-01-15T12:43:56Z'; 'nonce' with value 'd28348djsj3239'; and 'proofValue'
 with value 'zp2KaZ...8Fj3K='. This graph is annotated with the parenthetical
 remark '(a named graph)'">
@@ -1172,7 +1172,7 @@ <h3>Getting Started</h3>
         <p>
 After stabilizing all credential properties, developers are advised to generate
 and publish vocabulary and context files at stable URLs to facilitate
-interoperability with other developers. The 
+interoperability with other developers. The
 `https://www.w3.org/ns/credentials/examples/v2` URL above
 would then be replaced with the URL of a use-case-specific context. This
 process is covered in Section [[[#extensibility]]]. Alternatively,
@@ -7222,13 +7222,13 @@ <h2>application/vc</h2>
         </p>
 
         <p>
-The credential is expected to be a valid 
+The credential is expected to be a valid
 <a data-cite="JSON-LD11#dfn-json-ld-document">JSON-LD document</a>.
-Credentials served with the "`application/vc`" media type are expected 
-to have all [[JSON-LD11]] context information, including references to 
+Credentials served with the "`application/vc`" media type are expected
+to have all [[JSON-LD11]] context information, including references to
 external contexts, within the body of the document. Contexts linked via a
 `http://www.w3.org/ns/json-ld#context` HTTP Link Header
-(see <a data-cite="JSON-LD11#interpreting-json-as-json-ld">Section 6.1</a> 
+(see <a data-cite="JSON-LD11#interpreting-json-as-json-ld">Section 6.1</a>
 of [[JSON-LD11]]) are ignored.
         </p>
       </section>
@@ -7287,11 +7287,11 @@ <h2>application/vp</h2>
         <p>
 The presentation is expected to be a valid
 <a data-cite="JSON-LD11#dfn-json-ld-document">JSON-LD document</a>.
-Presentations served with the "`application/vp`" media type are expected 
-to have all [[JSON-LD11]] context information, including references to 
+Presentations served with the "`application/vp`" media type are expected
+to have all [[JSON-LD11]] context information, including references to
 external contexts, within the body of the document. Contexts linked via a
 `http://www.w3.org/ns/json-ld#context` HTTP Link Header
-(see <a data-cite="JSON-LD11#interpreting-json-as-json-ld">Section 6.1</a> 
+(see <a data-cite="JSON-LD11#interpreting-json-as-json-ld">Section 6.1</a>
 of [[JSON-LD11]]) are ignored.
         </p>
       </section>