Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Editorial] Terminology section or Glossary #7

Open
findthomas opened this issue Jun 7, 2024 · 5 comments
Open

[Editorial] Terminology section or Glossary #7

findthomas opened this issue Jun 7, 2024 · 5 comments
Assignees

Comments

@findthomas
Copy link

About you

Please include your name so your contribution can be publicly acknowledged in the final publication.

Name:

Organization/Company:

About your review

Document: EEA DLT Interoperability Specification

Section: Use the URL to identify the right section of the document.

Comments/Suggestions/Feedback

Would it make sense to have a Terminology or Glossary section?

Terms like "event attestation" could be defined in one or two sentences.

Same with "state attestation".

@chaals
Copy link
Contributor

chaals commented Jun 10, 2024

I tend to suggest defining terminology inline. Using Respec to generate specs, that gives us an index of all the terms we use, instead of a bunch of pages of definitions.

That said, I don't really care - this is an editorial question so the "right" answer is probably "what the group prefers".

@Aa-Ja
Copy link

Aa-Ja commented Jun 13, 2024

I would lean towards including a Terminology/Glossary section. While the index of terms would be a useful tool in itself, the Terminology/Glossary section would serve different purposes.

I see the Terminology/Glossary section as an opportunity to ensure uniformity and consistently when it comes to the use of terms in future written communications.

Can we create a Terminology/Glossary section based on the terms developed using Respec? Or would this just lead to pages of definitions?

@anaisofranc
Copy link
Contributor

Many terminologies and taxonomies have already been published. For example https://www.iso.org/obp/ui/en/#iso:std:iso:22739:ed-2:v1:en
The group is aligned with the commonly used terms. We will review the definitions of specific terms mentioned in the issue (event attestation and state attestation) to ensure completeness.

@anaisofranc
Copy link
Contributor

Event-attestation is described in section 3.4

"3.4 Event-based messaging mechanism
In an EVM-based environment, event attestation is a process that utilizes the block header's receipt root to prove that events occurred within that particular block. This receipt root is a cryptographic commitment to the list of transaction receipts, which in turn contain the smart contract event logs. The event data would typically contain information to trigger an action on the destination network."

And is further developed in section "3.4.3 Event Attestation".

@anaisofranc
Copy link
Contributor

The following has been added to the beginning of "3.5 State-based messaging mechanism".

"State attestation refers to the process of verifying and certifying the correctness of a network's state at a specific point in time. The primary goal is to ensure that the data presented is accurate and has not been tampered with."

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants