Andrieu/remove dereferencing function

[jandrieu]

This is an attempt to change just the minimum to remove the derefencing function.

This includes

1. Renamed "dereferencer" to "DID URL client"

2. Refactored the algorithm
   a. support the explicit step of determining the retrieval strategy based on the DID document.
   b. create coherent, prioritized heuristic for determining the retrieval strategy, based on the DID URL and the DID document. This explicitly suggests a hierarchy from Service -> serviceType -> property -> metadata -> did method specific -> just return DID document
   c. add the final step of using the resource, which is really the business purpose defined by the dereferencer

3. Removed network-based dereferencing

4. Removed dereferencing the fragment section as this is handled by "use the resource" section which defers to the media type of the resource.

5. Removed DID URL Dereferencing Result

6. Removed the dereferencing API and its HTTPS binding to reframe dereferencing as an algorithm to be executed by any client that wants to use a DID URL.

7. Separated the algorithms for service and service type for simplicity.

8. Removed the accept options for dereferencing, since there is no longer an http endpoint to receive it.

9. Added the step where the dereferencer selects a resolver for a given DID method.

---

Preview | Diff

[jandrieu]

After the initial PR, I realized I had introduced the term Base DID Url in the algorithm, but failed to add it to terms.html

Now fixed.

[jandrieu]

Also, especially for @TallTed, you'll note a lot of formatting changes. These are clean ups, either from replacing tabs with spaces or from aligning all of the HTML elements into a consistent indentation. It was nearly impossible to visually track which section I was in.

So apologies for the edits that seem like nothing. Formatting was a necessary step as a proof-read my edits.

[jandrieu]

@wip-abramson @ottomorac @peacekeeper @swcurran @msporny

This concludes the PRs I was asked to separate.

I could not make sense of any simpler way to remove the dereference function without adding the algorithm and the necessary updates to be integrated with that.

Hopefully this is easier to engage.

All the PRs are branched from main. I tried to minimize merge issues, but this last one will need hand tuning on merge conflicts.

[peacekeeper]

-1 to removing DID URL dereferencing as a logical function with well-defined inputs and outputs. Just to point out once more, the current spec is NOT saying that DID URL dereferencing needs to involve standalone libraries, or remote APIs, or anything like that.

-1 to removing the HTTPS binding for DID URL dereferencing, this would leave important use cases unspecified, as I explained in #306 (comment)

-1 to the term "DID URL resolution" that appears in this PR. We should stick to the clean and proven design that has worked well for many years, i.e. DID Resolution and DID URL Dereferencing.

-1 to removing the "accept" DID URL Dereferencing option, I think this contradicts your own proposal in #303

[dmitrizagidulin]

So apologies for the edits that seem like nothing. Formatting was a necessary step as a proof-read my edits.

@jandrieu do you mind submitting the formatting edits as a separate PR?

[jandrieu]

So apologies for the edits that seem like nothing. Formatting was a necessary step as a proof-read my edits.

@jandrieu do you mind submitting the formatting edits as a separate PR?

Sure. I can get to that this weekend.

[msporny]

So apologies for the edits that seem like nothing. Formatting was a necessary step as a proof-read my edits.
@jandrieu do you mind submitting the formatting edits as a separate PR?
Sure. I can get to that this weekend.

If we're going to re-flow the entire document, I have a request:

Do more-or-less proper indention for all HTML tags, but left justify all text blocks and line break before 80 characters.

This is what we do for many of the other W3C specs our community has worked on. ALT-Q will automatically do this for text blocks in Visual Code (other editors have similar setups). I typically do this right before FPWD, and right before CR, and then try to keep the document in shape throughout (other people putting PRs rarely do this and so I quietly reformat it so there is consistency throughout the document.

Left-justifying text blocks/content make PRs easier to review and leads to cleaner diffs.

The re-formatting I've seen in this PR (and a few others) has a stair-stepping effect that bunches a ton of text to the right, which exceeds the line breaks in most text editors... which then makes the linting rules in my text editor next to useless (because the entire document is lit up like a Christmas tree).

If we're going to do a re-flow of the entire document, we should be consistent. Additionally, this is the sort of thing that does not need to go through a PR, the Editors can do it on main since it's all editorial stuff. These sorts of re-flow changes are also highly disruptive to existing PRs (they will cause massive and almost irreconcilable merge conflicts -- which is why it's best to wait until PRs settle before doing them).

Just my $0.02.

[wip-abramson]

No sure how this got in here