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

Testability of normative DID Spec Registries statement on metadata #65

Open
msporny opened this issue Apr 18, 2021 · 7 comments
Open

Testability of normative DID Spec Registries statement on metadata #65

msporny opened this issue Apr 18, 2021 · 7 comments
Assignees

Comments

@msporny
Copy link
Member

msporny commented Apr 18, 2021

@shigeya wrote:

Let me quote the statement again here:

All metadata property definitions registered in the DID Specification Registries [DID-SPEC-REGISTRIES] MUST define the value type, including any additional formats or restrictions to that value (for example, a string formatted as a date or as a decimal integer).

From the core spec point of view, the above statement is not testable within the core spec. This spec text needs to be placed in DID-SPEC-REGISTRIES, not within core spec. I honestly have no idea whether we can treat this statement as "human testable."

From a different perspective: since the current test implementation runs the whole test against the transcript of interaction with multiple method implementations, it is desirable to test properties defined in DID-SPEC-REGISTRIES. In this case, we need a machine-readable -- at least partial -- DID-SPEC-REGISTRY.

I think there are three options:

  1. Eliminating the above statement
  2. Rewrite the above statement to move the test to DID-SPEC-REGISTRIES
  3. Rewrite the above statement to remove (direct) dependency on DID-SPEC-REGISTRIES.

It is possible to create an optional configuration parameter that may hold machine-readable (possibly partial) DID-SPEC-REGISTRIES, which can be usable for the above option 3.

(Note: due to schedule conflict, I can't attend the special topic call this week)

@msporny
Copy link
Member Author

msporny commented Apr 18, 2021

From the core spec point of view, the above statement is not testable within the core spec.

Correct.

This spec text needs to be placed in DID-SPEC-REGISTRIES, not within core spec.

Yes, agreed.

I honestly have no idea whether we can treat this statement as "human testable."

It is human testable. A human can check to see if "All metadata property definitions registered in the DID Specification Registries [DID-SPEC-REGISTRIES] define the value type, including any additional formats or restrictions to that value (for example, a string formatted as a date or as a decimal integer)."

I suggest we do the second option (if we don't have to go through another CR to do it), or just flag the statement as human testable and not something the WG intended to test. We have lots of these sorts of statements in the DID Methods section.

@shigeya
Copy link
Contributor

shigeya commented Apr 18, 2021

I suggest we do the second option (if we don't have to go through another CR to do it), or just flag the statement as human testable and not something the WG intended to test.

Fully agreed.

We have lots of these sorts of statements in the DID Methods section.

I will review them.

@shigeya
Copy link
Contributor

shigeya commented Apr 26, 2021

When I look for the word DID-SPEC-REGISTRIES in did-core-test-suite, there are only two files with the word. That's a very small number. Also, one of the file is on metadata which I'm working on.

From the point of view of completeness of the test, and also for creation of a report, I think it is better to include human testable statements in the test suite as a todo() with some easy-to distinguish prefix ( [Require human test] or similar? ).

For example, in Section 5.2. Verification Method, the following statements are missing as test statements.

A verification method MAY include additional properties. Verification methods SHOULD be registered in the DID Specification Registries [DID-SPEC-REGISTRIES].

In order to maximize global interoperability, the verification method type SHOULD be registered in the DID Specification Registries [DID-SPEC-REGISTRIES].

In Section 5.3:

In order to maximize global interoperability, any such properties used SHOULD be registered in the DID Specification Registries [DID-SPEC-REGISTRIES].

In Section 5.4:

In order to maximize interoperability, the service type and its associated properties SHOULD be registered in the DID Specification Registries [DID-SPEC-REGISTRIES].

etc.

@msporny
Copy link
Member Author

msporny commented Apr 30, 2021

From the point of view of completeness of the test, and also for creation of a report, I think it is better to include human testable statements in the test suite as a todo() with some easy-to distinguish prefix ( [Require human test] or similar? ).

At this point, this isn't done, and is unlikely to be done before the cut off on Tuesday. I suggest we don't do this (or could do it later). Take a look at issue #72 - #76 -- we are just not adding marks to the checkboxes that are associated the human-readable tests during the audit.

@shigeya
Copy link
Contributor

shigeya commented Apr 30, 2021

@msporny thanks. I understand the plan.

From the consistency point of view, do you want to me to remove the human testable statements (currently marked todo()) from the test?

@msporny
Copy link
Member Author

msporny commented Jun 6, 2021

From the consistency point of view, do you want to me to remove the human testable statements (currently marked todo()) from the test?

Yes, at this point we should just remove all .todo() statements from the test suite. I don't think they're being used by anyone.

shigeya added a commit to shigeya/did-test-suite that referenced this issue Jun 6, 2021
As discussed in w3c#65, removed `todo` for the following statement:
	7.3 Metadata Structure - All metadata property definitions
	registered in the DID Specification Registries
	[DID-SPEC-REGISTRIES] MUST define the value type,
	including any additional formats or restrictions to
	that value (for example, a string formatted as a date
	or as a decimal integer).
@shigeya
Copy link
Contributor

shigeya commented Jun 6, 2021

@msporny Created a PR for 7.3.

Found that the following in is still a todo in did-url-dereferencing.js:

it.todo('3.2.2 Relative DID URLs - When resolving a relative DID URL reference, the algorithm specified in RFC3986 Section 5: Reference Resolution MUST be used.');

msporny pushed a commit that referenced this issue Jun 8, 2021
As discussed in #65, removed `todo` for the following statement:
	7.3 Metadata Structure - All metadata property definitions
	registered in the DID Specification Registries
	[DID-SPEC-REGISTRIES] MUST define the value type,
	including any additional formats or restrictions to
	that value (for example, a string formatted as a date
	or as a decimal integer).
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

2 participants