Clarify headings for dereferencing primary/secondary resource

[peacekeeper]

This expands the names of the sections about dereferencing the primary/secondary resources.

I'm actually not sure if I am in favor of merging this, since it results in longer headning. But I wanted to capture this since it has been brought up in last week's DID WG meeting.

[danpape]

I agree adding these clarifications this way would make the subsection headings quite large and may mess up the nice table of contents on the respec page. Could the verbiage about what we mean by primary and secondary resources be put in the "4.3 Algorithm" intro paragraph?

[pchampin]

This was discussed during the #did meeting on 12 September 2024.

[mccown]

I would be happy either way on this. The extra text will help guide readers -- especially new readers. However, I don't think it's strictly necessary. Generally, I'm in favor of things that help new adopters.

[peacekeeper]

I agree with @danpape 's comment. The problem here is not the headings, it's that maybe the meanings of "primary resources" and "secondary resource" aren't clear enough. I was trying to use them as they are defined in RFC3986, but am also open to using different terms.

[decentralgabe]

Suggested change

	<h2>Dereferencing the Primary Resource (DID document or other resource)</h2>
	<h2>Dereferencing the Primary Resource (DID Document or other resource)</h2>

do we keep these both caps?

[pchampin]

This was discussed during the #did meeting on 19 September 2024.

View the transcript

DID Resolution PR 88 / 89

"w3c/did-resolution#88

w3c/did-resolution#89"

Simplify dereferencing of the DID fragment based on the media type

Wip: I put this on the agenda. We talked about it last week. Should the primary resource be the DID Document? it says 'first you get the DID Document in resolution, then primary resource...'

<swcurran> +1 to WIP about primary document

markus_sabadello: agree, lets not have a big discussion about the naming of primary and secondary resource. I have been using the terms as introduced in original rfc3936
… PR 88 is an attempt to remove language related to processing the fragment. This depends on the media type
… Currently the text is specific to a JSONLD document. The intent of the PR is to simplify and remove this part
… regarding the discussion of primary and secondary resource lets have a special topic about it. It effects a lot of things

manu: Fine with 88 being merged. Agree there was confusion with primary and secondary resource. I also found the current spec text clear on that
… not blocking 88

decentralgabe: We will plan on a special topic call for 88 and 80 around this resource discussion

---

[OKEAMAH]

Cv