Fix grammar/flow in Section 2.1 Proofs.

index.html

@@ -661,57 +661,58 @@ <h2>Data Model</h2>
 
       <p>
 This section specifies the data model that is used for expressing
-[=data integrity proofs=], [=controller documents=], and
-[=verification methods=].
+[=data integrity proofs=] and the integrity of related resources.
       </p>
 
       <p>
 All of the data model properties and types in this specification map to URLs.
-The vocabulary where these URLs are defined is the [[?SECURITY-VOCABULARY]]. The
-explicit mechanism that is used to perform this mapping in a secured document is
-the `@context` property.
+The vocabulary where these URLs are defined is the [[[?SECURITY-VOCABULARY]]].
+The explicit mechanism that is used to perform this mapping in a secured
+document is the `@context` property.
       </p>
 
       <p>
-The mapping mechanism is defined by JSON-LD [[JSON-LD11]]. To ensure a document
-can be interoperably consumed without the use of a JSON-LD library, document authors
-are advised to ensure that domain experts have 1) specified the expected order for
-all values associated with a `@context` property, 2) published cryptographic hashes
-for each `@context` file, and 3) deemed that the contents of each `@context` file
-are appropriate for the intended use case.
+The mapping mechanism is defined by [[[JSON-LD11]]]. To ensure a document can be
+interoperably consumed without the use of a JSON-LD library, document authors
+are advised to ensure that domain experts have 1) specified the expected order
+for all values associated with a `@context` property, 2) published cryptographic
+hashes for each `@context` file, and 3) deemed that the contents of each
+`@context` file are appropriate for the intended use case.
       </p>
 
       <p>
-When a document is processed by a non-JSON-LD processor and there is a
-requirement to use the same semantics as those used in a JSON-LD environment,
-implementers are advised to 1) enforce the expected order and values in the
-`@context` property, and 2) ensure that each `@context` file matches the known
-cryptographic hashes for each `@context` file.
+When a document is processed by a processor that does not utilize JSON-LD
+libraries, and there is a requirement to use the same semantics as those used in
+a JSON-LD environment, implementers are advised to 1) enforce the expected order
+and values in the `@context` property, and 2) ensure that each `@context` file
+matches the known cryptographic hashes for each `@context` file.
       </p>
 
       <p>
-Using static, versioned `@context` files with published cryptographic hashes in
+Using static, versioned, `@context` files with published cryptographic hashes in
 conjunction with JSON Schema is one acceptable approach to implementing the
 mechanisms described above, which ensures proper term identification, typing,
-and order, when a non-JSON-LD processor is used.
+and order, when a processor that does not utilize a JSON-LD library is used.
+See the section on
+<a data-cite="?VC-DATA-MODEL-2.0#type-specific-credential-processing">
+Type-Specific Processing</a> in [[[?VC-DATA-MODEL-2.0]]] for more details.
       </p>
 
       <section>
         <h3>Proofs</h3>
         <p>
 A [=data integrity proof=] provides information about the proof mechanism,
-parameters required to verify that proof, and the proof value itself. All of this
-information is provided using Linked Data vocabularies such as the
-[[?SECURITY-VOCABULARY]].
+parameters required to verify that proof, and the proof value itself. All of
+this information is provided using Linked Data vocabularies such as
+[[[?SECURITY-VOCABULARY]]].
         </p>
 
         <p>
 When expressing a [=data integrity proof=] on an object, a
-<dfn class="lint-ignore">`proof`</dfn> property MUST be used.
-The `proof` property within a Verifiable Credential is a named graph.
-If present, its
-value MUST be either a single object, or an unordered set of objects, expressed
-using the properties below:
+<dfn class="lint-ignore">`proof`</dfn> property MUST be used. The `proof`
+property within a [=verifiable credential=] is a [=named graph=]. If present,
+its value MUST be either a single object, or an unordered set of objects,
+expressed using the properties below:
         </p>
 
         <dl style="margin-left: 1em;">
@@ -737,10 +738,9 @@ <h3>Proofs</h3>
 being misused by being applied to a purpose other than the one that was
 intended. For example, without this value the creator of a proof could be
 tricked into using cryptographic material typically used to create a Verifiable
-Credential (`assertionMethod`) during a login process
-(`authentication`) which would then result in the creation of a
-Verifiable Credential they never meant to create instead of the intended action,
-which was to merely logging into a website.
+Credential (`assertionMethod`) during a login process (`authentication`) which
+would then result in the creation of a Verifiable Credential they never meant to
+create instead of the intended action, which was to merely log in to a website.
           </dd>
 
           <dt>verificationMethod</dt>