-
Notifications
You must be signed in to change notification settings - Fork 45
Conversation
Signed-off-by: Michael Lodder <redmike7@gmail.com>
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.
This is good, yes let's finally add support for the missing did-query
. But some details should be changed I think regarding query+fragment, see inline comments.
(i.e., it does NOT contain a path or fragment), | ||
then the DID query operates directly against the DID document.</p> | ||
|
||
<p>If a DID is followed by a DID fragment followed immediately by a DID query component, |
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.
This paragraph doesn't make sense to me. did-fragment
comes after did-query
.
then the DID query operates against the branch of the DID document | ||
specified DID document fragment.</p> | ||
|
||
<p>A DID method specification MAY defined its own DID fragment query syntax.</p> |
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.
What's the motivation here?
A generic <a>DID query</a> (the did-query rule in Section <a href="#the-generic-did-scheme"></a>) is identical to a URI search and MUST | ||
conform to the ABNF of the query rule in [[RFC3986]]. | ||
<p>If a DID is followed immediately by a DID query component | ||
(i.e., it does NOT contain a path or fragment), |
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.e., it does NOT contain a path or fragment), | |
(i.e., it does NOT contain a path), |
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 think the point is that the query operations on what the path resolves too. Currently if there is no path the default is the path resolves to the DDO likewise if there is not path then the fragment resolves against the DDO. The query applies to what ever the path resolves too. The query usually does not apply to a fragment but to the resource. However because the did fragment has special semantics we could give special meaning to the query if a did fragment is present. I like the change does not contain a path and let the implementer decide what to do if a did fragment is present but not path.
Would be good to rewrite the commit message to say what patch does vs just saying it addresses an issue number. |
Addressed/refactored in PR #168. |
Replaced by PR #189. |
Signed-off-by: Michael Lodder redmike7@gmail.com
Addresses issue 85
Preview | Diff