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

Define resolution function with data types and property values #297

Conversation

jricher
Copy link
Contributor

@jricher jricher commented May 27, 2020

This adapts the DID Resolution functional definition defined by #253 into a single typed function with requirements for the function signature and implementation conformance. Property values for input and output metadata structures are defined here, with pointers to the DID registry for management of properties. Requirements for when and how to return each value are also added.

This builds on #295 and #296.


Preview | Diff


<p><code>
resolve ( did, did-resolution-input-metadata ) <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-&gt; ( did-resolution-metadata, did-document-stream, did-document-metadata )
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this syntax for these functions described somewhere? Hard to tell looking at this if this can be an async function (in languages that do that). A JavasScript implementation would probably return a Promise here. Is the output a tuple or map with named properties? Seems kind of a fuzzy description for a "MUST". In the JSON-LD API spec we used WebIDL for these API descriptions. Has some rough edges but seemed to work good enough and has some respec support. The LoadDocumentCallback API has a similar pattern to this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Those details depend on your language. It's pretty clear in any implementation what "call a function" and "return a value" mean, and it's different for each one.

Here, we're not specifying if it's synchronous or not, so a promise-based resolution would be fine. We're also not specifying how multiple outputs are returned, so a tuple, or an encapsulating object, or a bunch of pointers will all be fine.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's confusing to use language like "all conformant implementations MUST implement a function in the following form". In a spec I read this as something strict. But here it involves guessing what the ad-hoc function call description means, and understanding it can be sync/async, use tuples, objects, or pointers (for parameters and results maybe?), and I'm guessing the actual names are not required either since many languages can't handle - in identifiers. What form is it that must be followed?

Copy link
Member

@kdenhartog kdenhartog left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Additional information looks good. Have question in #296 which would be resolved in that PR and then brought in here, so not concerned with starting the discussion twice.

@msporny
Copy link
Member

msporny commented Jul 3, 2020

PR #331 has been merged. @jricher, can we close this PR now?

@peacekeeper
Copy link
Contributor

peacekeeper commented Jul 3, 2020

@jricher do you agree we can close this now that #331 has been merged (since that PR also includes the new incremental commit from this PR here)?

(EDIT: oops, @msporny beat me to it)

@msporny msporny closed this Jul 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
do not merge Do not merge - waiting on resolution to issue
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants