DID Fragment semantics cleanup needed

[iherman]

(This may or may not be an editorial issue, depending on the alternatives below)

The definition of Fragments in §3.2.4 looks incomplete to me.

In an HTTP setting the HTTP protocol means first returning the (complete) resource to a client which then, as a second step, takes a portion of that resource using the fragment ID. If my understanding is correct, this is not exactly what happens in the DID URL world: the §8.2 DID URL Resolver returns the final (whatever it is) resource, i.e., it is up to the DID URL Resolver to take care of the fragment identifier processing result.

1. Is this correct? If so, this clarification should be, in my view, explicitly stated either in §3.2.4. or in §8.2 (or both)
2. If this is not the case, then we have an additional problem: if one looks at §8.2.2 the media type is returned (so that the client of the DID URL can handle it) as a dereferencing metadata. However, returning that metadata property is OPTIONAL, meaning that, potentially, a resource is returned and the client does not know what to do with the fragment ID. Shouldn't it be the case that, when the DID URL includes a fragment, the media type be REQUIRED in the return metadata?

(I hope the answer to the question is (1) above :-)

[peacekeeper]

@iherman yes the answer is 1., i.e. the dereference() function returns the final resource identified by the DID URL (including fragment). BTW, in your text above you probably meant to say DID URL dereferencer rather than DID resolver (both terms exist in the terminology).

The reason why we didn't explicitly state this is that we wanted to define this as an abstract function, but not go into details of how exactly a DID URL is dereferenced. There is quite a bit of content in the DID Resolution spec, e.g. it distinguishes between dereferencing the primary resource vs. the secondary resource, and it talks about the fact that different portions of the dereferencing process can be done by different components (e.g. Client-Side Dereferencing).

That said, personally I wouldn't be opposed to adding the clarification you mention to section 8.2 of DID Core, i.e. add a statement that dereference() returns the "final" resource.

[iherman]

@iherman yes the answer is 1., i.e. the dereference() function returns the final resource identified by the DID URL (including fragment). BTW, in your text above you probably meant to say DID URL dereferencer rather than DID resolver (both terms exist in the terminology).

Oops, sorry.

The reason why we didn't explicitly state this is that we wanted to define this as an abstract function, but not go into details of how exactly a DID URL is dereferenced. There is quite a bit of content in the DID Resolution spec, e.g. it distinguishes between dereferencing the primary resource vs. the secondary resource, and it talks about the fact that different portions of the dereferencing process can be done by different components (e.g. Client-Side Dereferencing).

That said, personally I wouldn't be opposed to adding the clarification you mention to section 8.2 of DID Core, i.e. add a statement that dereference() returns the "final" resource.

I believe something should be said without getting into the details. The specification should be readable by itself.

[jonnycrunch]

I think this also impacts: #452

[msporny]

PR #544 addressed this issue and has been merged. Closing.