Update ERC-7208: fixes to example + grammar

Merged by EIP-Bot.

ERCS/erc-7208.md

@@ -14,7 +14,9 @@ requires: 165
 ## Abstract
 
 
-"On-chain Data Containers" (ODCs) are used for indexing and storing data in Smart Contracts called "Data Objects" (DOs). Information stored in Data Objects can be accessed and modified by the implementation of smart contracts called "Data Managers" (DMs). This ERC defines a series of interfaces for the separation of the storage of data from the implementation of the logic functions that govern such data. We introduce the interfaces for ODCs, the structures associated with DOs for abstracting storage, the DMs to access or modify the data, and finally the interfaces for compatibility Registries that enable Data Portability (horizontal mobility) between different implementations of this ERC.
+
+"On-chain Data Containers" (ODCs) are used for indexing and storing data in Smart Contracts called "Data Objects" (DOs). Information stored in Data Objects can be accessed and modified by implementing smart contracts called "Data Managers" (DMs). This ERC defines a series of interfaces for the separation of the storage of data from the implementation of the logic functions that govern such data. We introduce the interfaces for ODCs, the structures associated with DOs for abstracting storage, the DMs to access or modify the data, and finally the interfaces for compatibility Registries that enable Data Portability (horizontal mobility) between different implementations of this ERC.
+
 
 
 
@@ -24,7 +26,9 @@ As the Ethereum ecosystem grows, so does the demand for on-chain functionalities
 
 While such diversity spurs innovation, different projects will implement their bespoke solutions for interoperability, resulting in a highly fragmented landscape. The lack of a standard mechanism for adapting tokenized across ERC standards is accentuating the interoperability issues.
 
-We recognize there is no “one size fits all” solution to solve the standardization and interoperability challenges. Most assets - either Fungible, Non-Fungible, Digital Twins, Real-world Assets, DePin, etc - have multiple mechanisms for representing them as on-chain tokens by utilizing different standard interfaces. However, for those assets to be exchanged, traded, or interacted with, protocols are required to implement each of those standards to be able to access and modify the on-chain data. Moreover, the immutability of smart contracts plays a role against future-proofing their implementations by supporting new tokenization standards. A collaborative effort must be made to enable On-chain Adapters to enable the interaction between assets tokenized under different standards. 
+
+We recognize there is no “one size fits all” solution to solve the standardization and interoperability challenges. Most assets - Fungible, Non-Fungible, Digital Twins, Real-world Assets, DePin, etc - have multiple mechanisms for representing them as on-chain tokens using different standard interfaces. However, for those assets to be exchanged, traded, or interacted with, protocols must implement compatibility with those standards before accessing and modifying the on-chain data. Moreover, the immutability of smart contracts plays a role in future-proofing their implementations by supporting new tokenization standards. A collaborative effort must be made to enable interaction between assets tokenized under different standards. The current ERC provides the tools for developing such On-chain Adapters.
+
 
 We aim to abstract the on-chain data handling from both the logical implementation and the ERC interfaces exposing the underlying data. This EIP proposes a series of interfaces for storing and accessing data on-chain, codifying the underlying assets as generic "Data Points" that may be associated with multiple interoperable and even concurrent ERC interfaces. This proposal is designed to work by coexisting with previous and future token standards, providing a flexible, efficient, and coherent mechanism to manage asset interoperability.
 
@@ -42,7 +46,8 @@ We aim to abstract the on-chain data handling from both the logical implementati
 
 ### Terms
 
-**ODC**: A uniquely identifiable data container that is used for indexing Data Objects or storing Data Points.
+
+**ODC**: A uniquely identifiable data structure used for indexing Data Objects or storing Data Points.
 
 **ODC Implementation**: One or many Smart Contracts implementing the ODC access-management logic.
 
@@ -56,7 +61,8 @@ We aim to abstract the on-chain data handling from both the logical implementati
 
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
 
-### ODC
+
+### ODC Interface
 
  * ODC SHOULD manage internal IDs for each data container.
  * ODC SHOULD manage the access of Data Managers to Data Objects.
@@ -121,7 +127,8 @@ interface IODC {
 }
 ```
 
-### Data Objects
+
+### Data Object Interface
 
  * Data Object SHOULD implement the logic directly related to handling the data stored on Data Points.
  * Data Object SHOULD implement the logic for transfering management of its Data Points to a different ODC Implementation.
@@ -161,7 +168,8 @@ Data Objects can receive `read()` or `write()` requests when a Data Manager is r
 The function `setODCImplementation()` SHOULD enable the delegation of the the management function to an IODC implementation.
 
 
-### Data Points
+
+### Data Point Structure
 
 * Data Point SHOULD be `bytes32` storage units.
 * Data Point SHOULD use a 4 bytes prefix for storing information relevant to the compatibility with other Data Points.
@@ -185,7 +193,9 @@ The function `setODCImplementation()` SHOULD enable the delegation of the the ma
 **/
 ```
 
-### Data Point Registry
+
+### Data Point Registry Interface
+
 
  * Data Point Registry SHOULD store Data Point access management data for Data Managers and Data Objects
  * Data Point Registry SHOULD use the IDataPointRegistry interface:
@@ -234,7 +244,8 @@ interface IDataPointRegistry {
 }
 ```
 
-### Data Managers
+
+### Data Manager Contract
 
  * Data Manager MAY use read() or DataObject.read() to read data form Data Objects
  * Data Manager MAY use write() to write data to Data Objects
@@ -247,9 +258,10 @@ Data Managers are independent smart contracts that implement the business logic.
 
 ## Rationale
 
-The decision to encode Data Points as bytes32 data containers is primarily driven by flexibility and future-proofing. Using bytes32 allows for a wide range of data encodings. This provides the developer with flexibility to accommodate diverse use cases. Furthermore, as Ethereum and its standards continue to evolve, encoding as bytes32 ensures that the Standard Adapters can support future data types or structures without requiring significant changes to the standard adapter itself. The Data Point encoding should have a prefix so that the Data Object can efficiently identify compatibility issues when accessing the data storage. Additionally, the prefix should be used to find the Data Point Registry and verify admin access of the Data Point. The use of a suffix for identifying the Data Point Registry is also required, in order for the Data Object to quickly discard badly formed transactions that aim to use a Data Point from an unmatching Data Point Registry.
 
-Data Objects being independent separate Smart Contracts that implement the same `read`/`write` interface for communicating with Data Managers is a decision mainly driven by the scalability of the system. Offering a simple interface for this 2-layer structure enables different applications to have their own addresses for storage of data as well as assets. It is up to each implementation to manage access to this Data Point storage space. This enables a wide array of complex, dynamic, and interactive use cases to be implemented with multiple ERCs as well as other smart contracts.
+The decision to encode Data Points as bytes32 data containers is primarily driven by flexibility and future-proofing. Using bytes32 allows for a wide range of data encodings. This provides the developer with many options to accommodate diverse use cases. Furthermore, as Ethereum and its standards continue to evolve, encoding as bytes32 ensures that the Standard Adapters can support future data types or structures without requiring significant changes to the standard adapter itself. The Data Point encoding should have a prefix so that the Data Object can efficiently identify compatibility issues when accessing the data storage. Additionally, the prefix should be used to find the Data Point Registry and verify admin access of the Data Point. The use of a suffix for identifying the Data Point Registry is also required, for the Data Object to quickly discard badly formed transactions that aim to use a Data Point from an unmatching Data Point Registry.
+
+Data Objects being independent separate Smart Contracts that implement the same `read`/`write` interface for communicating with Data Managers is a decision mainly driven by the scalability of the system. Offering a simple interface for this 2-layer structure enables different applications to have their addresses for storage of data as well as assets. It is up to each implementation to manage access to this Data Point storage space. This enables a wide array of complex, dynamic, and interactive use cases to be implemented with multiple ERCs as well as other smart contracts.
 
 Data Objects offer flexibility in storing mutable on-chain data that can be modified as per the requirements of each specific use case. This enables the Data Managers to hold mutable states in delegated storage and reflect changes over time, providing a dynamic layer to the otherwise static nature of storage through most other standardized interfaces.