Needed a help on improving diagrams (reducing complexity, relocation, and addition)

[shigeya]

Since PR #612 which Ivan posted the part of minutes of a meeting on 2021-02-11 is already closed, let me open an issue.

Manu Sporny: if it can get into google draw, that seems to be a useful thing … if not we can recreate it … we just want to get it into a format we can iterate on … The other question was layout with the diagram, I’m sure you’ve tried to lay it out in a way that’s easier … I’m wondering if we can simplify further and reduce arrows to the minimum … it could be that DID URL and DID URL dereferencing could be a different diagram, down in the URL dereferencing section … that may simplify the diagram further … ideally I think we want 5 concepts in the diagram. 6 to 7 is a bit much … at this point we have 15 including the arrows … I really appreciate all the work in the diagram … trying to see how aggressively simplified we can get

@msporny After reviewing possibilities of reducing the complexity, I found that I need to have a tip:

The idea of Figure 1 is to capture the relationships of all of the elements that appear in section 1.3 Architecture Overview. Removing any element or arrow will eliminate the visual relationship or the element in the section. I think the diagram and texts in the section need to be in sync. Do you have any suggestions to solve this contradiction? Note, replacing the text fragment refers, and dereferences, to to dereference to seems possible.

For the diagram for dereferencing section, I will create a simplified version of the detailed diagram which captures the document-fragment dereference. This is because it was difficult to understand how #fragment notation works for me. I believe the diagram will help understand how document-relative fragment dereference works. I will create a PR on this.

[msporny]

There have been a number of PRs that have been merged related to diagrams in the specification - PRs #681, #692, #690, and #700. I believe this issue has been addressed, so am marking this as pending close.

@shigeya, can you please confirm -- can we close this issue?

[shigeya]

@msporny I think we can close.

The initial reason for this issue is to ask you what kind of diagrams we want. I think merging #700 (alongside with prior PR) resolves this issue.

For clarification:

• PR #690 addresses the ECHIDNA issue related to the previously merged diagram (Figure 1 replacement).
• While the improvements on PR #681 #692 look good, they are on models, and not directly related to this issue.