Re: Clarity on DID Resolution as it refers to DID WG

> On 20 Apr 2020, at 23:37, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
> On 4/20/20 4:45 PM, Justin Richer wrote:
>> I am hoping we’re not as far apart on our interpretation of
>> things as it might seem, and so here is my counter proposal
>> to your set of conclusions on the interpretation of the
>> charter bullet point list
> 
> Thanks for the concrete counter-proposal, Justin. I'll go through each
> item to clarify the proposal we may want to put in front of the group:
> 
>> * It is in scope for the DID WG to normatively define the >   parameters of a concrete set of processes that>   take a DID as
> input and provides a DID Document as>   output.
> Agree.
> 
>> * It is in scope to normatively define the parameters
>>   of a concrete set of processes that take a DID URL
>>   as input and provide a resource result as output.
> 
> Agree.
> 
>> * It is in scope to make these processes take in options and
>>   provide back a document along with different
>>   classes of metadata (e.g., document metadata and
>>   resolution metadata).
> 
> Agree.
> 
>> * It is in scope to add tests to the test suite that exercise
>>   the callers of these processes and test the generation
>>   of DIDs and DID URLs as well as the processing of
>>   DID Documents and associated metadata. 
> 
> Close. Strike "the callers". There are multiple valid ways to test this
> and we should avoid painting ourselves into a corner.
> 
>> * It is out of scope to add resolution tests to the test
>>   suite that exercise the generalized DID resolution
>>   process in the specification on concrete DID Method
>>   implementations.
> 
> Disagree.

Coming in a bit late in the discussion, and not being present on the topic calls: I think we would need some more information on what this statements, and the disagreements around them, really mean.

From a process point of view: the charter, and indeed the W3C process, does _not_ give any restriction on _how_ a particular feature is tested. The goal of the CR testing, again per process, is to prove that the specification (more exactly, the normative part of the specification) is consistent, is implementable (usually required to be implemented by two independent implementations of some sort), and is interoperable, ie, independent implementations implement the features the same way based on the specification and based _only_ on the specification. How exactly this testing is done is up to the WG to define and the WG must convince the Director that the testing methodology is suited to these general goals.

Testing can be very different. Browser-dependent features (eg, various Web APIs) are usually tested these days via a complex and (semi-)automatic test suite that makes use, for example, of headless clients. Other testing approaches define some sort of a test manifest format accompanied by large collection of test cases; implementations self-test and return a manifest instance of their testing results to the WG (that usually compiles a suitable report out of those). This is what is happening, for example, in the JSON-LD Working Group right now. The situation is even more complex when the specification is, for example, a vocabulary: there is no 'executable' tests, and the tests are more to prove that "implementations" (ie, users) of those vocabularies really make use of the defined terms. Etc.

Can someone describe me, in light of that, what exactly is meant by these items and what the underlying disagreements are? Because my first reaction is that how tests are done is not a matter of the charter, i.e., the interpretation of the charter in the first place!

Thanks

Ivan



> 
>> * It is out of scope to normatively define DID Method specific
>>   details of implementing DID resolution.
> 
> Agree.
> 
>> * It is out of scope to normatively define DID Resolution
>>   protocols.
> 
> Agree.
> 
>> * It is out of scope to test concrete DID Resolution
>>   protocols and data formats beyond the necessary
>>   process to demonstrate interoperability between the
>>   test suite and an implementation.
> 
> Agree.
> 
> So, we're very close. :)
> 
> -- manu
> 
> -- 
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> blog: Veres One Decentralized Identifier Blockchain Launches
> https://tinyurl.com/veres-one-launches
> 


----
Ivan Herman, W3C 
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: https://orcid.org/0000-0003-0782-2704

Received on Tuesday, 21 April 2020 06:54:40 UTC