Implement Data Model / Resolution serialization mechanisms.

[msporny]

Implements the following WG decision:

RESOLUTION: The ADM is only used to represent a DID document or parts of a DID document (e.g. a verification method). For DID Resolution data structures, INFRA will be referenced normatively, as well as the JSON serialization rules for INFRA, to note that the data structure must be able to be serialized using INFRA->JSON rules.

https://www.w3.org/2021/02/16-did-topic-minutes.html#r01

---

Preview | Diff

[msporny]

This PR is blocked waiting on a review from: @peacekeeper and @jricher

[msporny]

@brentzundel merged:

Merge branch 'main' into msporny-cr-fix-data-model

Just as an FYI for those doing multi-headed merges -- we try very hard to not do that in this repo; instead we rebase. Multi-headed merges, while they seem to get rid of merge conflicts, don't actually get rid of merge conflicts when you're rebasing.

We do rebasing in this repo (and I'd go as far as to say it's a best practice in ALL git repositories) because it gives you a clear chronological order wrt. when changes were applied to the files in a repository. With rebasing, you get a very clear: Fix X, Add Y, then Delete Z, ordering. That also why (we're supposed to be using) active voice for all commits. If you use active voice for all commit messages, and do rebasing, then you can read the history of a git repository like you would a story.

I've been trying to look for a CI job that enforces this on commits so I don't have to keep rewriting history for PRs (which I don't mind doing, other than it might not be aligned with what folks wanted the history to look like). Also, I don't want to raise the bar for submitting a PR to the point that it's difficult to do -- requiring people to know about rebasing, rewriting history, etc... would reduce the number of people capable of submitting a PR.

So there you go, more than you ever wanted to know about this repos git history hygiene.

[msporny]

Substantive, multiple positive reviews, no changes requested, no objections, merging.

[brentzundel]

@brentzundel merged:

Merge branch 'main' into msporny-cr-fix-data-model

Just as an FYI for those doing multi-headed merges -- we try very hard to not do that in this repo; instead we rebase. Multi-headed merges, while they seem to get rid of merge conflicts, don't actually get rid of merge conflicts when you're rebasing.

We do rebasing in this repo (and I'd go as far as to say it's a best practice in ALL git repositories) because it gives you a clear chronological order wrt. when changes were applied to the files in a repository. With rebasing, you get a very clear: Fix X, Add Y, then Delete Z, ordering. That also why (we're supposed to be using) active voice for all commits. If you use active voice for all commit messages, and do rebasing, then you can read the history of a git repository like you would a story.

I've been trying to look for a CI job that enforces this on commits so I don't have to keep rewriting history for PRs (which I don't mind doing, other than it might not be aligned with what folks wanted the history to look like). Also, I don't want to raise the bar for submitting a PR to the point that it's difficult to do -- requiring people to know about rebasing, rewriting history, etc... would reduce the number of people capable of submitting a PR.

So there you go, more than you ever wanted to know about this repos git history hygiene.

Apologies. I was trying to help by fixing merge conflicts.

[msporny]

@brentzundel wrote:

Apologies. I was trying to help by fixing merge conflicts.

No problem, and I appreciate the effort... just trying to save your time in the future... rebasing overwrites merges, so it becomes a no-op... your valuable time is better spent doing other non-merge-y stuff. :)