-
Notifications
You must be signed in to change notification settings - Fork 98
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
full editing pass on all terms #335
Conversation
Signed-off-by: Drummond Reed <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit concerned about internal links to sections in the DID spec, which won't work if these terms are pulled into another spec (eg. Use Cases). That needn't necessarily hold up this PR, we can fix them later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
minor nits here and there, but looking good so far!
section of the <a href="https://w3.org/TR/did-core">DID Core specification</a>. | ||
Each <a>DID method</a> specification must define a specific DID | ||
scheme that works with that specific <a>DID method</a>. In a specific DID method | ||
scheme, the DID method name must follow the first colon and terminate with the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this properly align with did submethod names? It may be better to define that as a separate term or not make mention of it here because I'm not sure if that concept is well defined through out the specification.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kdenhartog You're right that we do not currently have a formal definition of a "submethod name". So it's an open issue whether we want to formalize that or not. What's your feeling about that? Do you think we should make it a formal concept in the spec? And reflect that in how we structure the ABNF? (Which BTW would not be any normative change to the syntax, just how how we talk about it.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking it will be useful to define them. Having that language in place in my mind will be helpful when describing the network of networks approach as well as ways that the identifiers can be modified to address forking concerns. Even if we don't explicitly mention them within the text now, I think by defining the term we'll seed the idea of being able to use that technique into DID Method author's mind in the which will allow it to be used in creative ways.
This could likely be done as a separate issue though and doesn't need to block this in order for it to be completed.
The entity the <a>DID document</a> is about. That is, the entity identified by | ||
the <a>DID</a> and described by the <a>DID document</a>. | ||
The entity identified by a <a>DID</a> and described by a <a>DID document</a>. A | ||
<a>DID</a> has exactly one DID subject. Anything can be a DID subject: person, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agree with Amy Co-authored-by: Amy Guy <[email protected]>
good catch Co-authored-by: Kyle Den Hartog <[email protected]>
good suggestion from Kyle Co-authored-by: Kyle Den Hartog <[email protected]>
Co-authored-by: Kyle Den Hartog <[email protected]>
Editorial, multiple reviews, changes requested and made, no objections, merged. |
Signed-off-by: Drummond Reed [email protected]
Preview | Diff