Why is Linkset required to be an additional resource rather than a representation?

[gibsonf1]

lws-protocol/lws10-core/Operations/metadata.md

Line 13 in d8a4de3

**The Linkset Resource**

Why not require Linkset to be a representation delivered when requested instead? Requiring this to be a resource specifies implementation specifics that go beyond scope. In TwinPod, we would not make an additional resource for the resource (since all resources are already data), but just send the representation per spec when requested on that resource, likely using ?meta in the query string for user to request it.

[pchampin]

Why not require Linkset to be a representation delivered when requested instead?

See the last two paragraphs in #127 (comment).

Requiring this to be a resource specifies implementation specifics that go beyond scope.

I disagree.

In TwinPod, we would not make an additional resource for the resource (since all resources are already data),

Well, that seems to be implementation specific...

but just send the representation per spec when requested on that resource, likely using ?meta in the query string for user to request it.

Oh! Then we are not talking about the same thing when using the term "representation". I'm referring to it as defined in https://www.w3.org/TR/webarch/ . I.e., a resource (identified by a URI) may return different representations based on different aspects of the request: time (if its state changes), content-negotiation (via accept, accept-language...), other aspects (e.g. user-agent, client's IP address)... But they all represent the same resource, identify by the same URI.

If you append ?meta to the URI of a resource, you are essentially identifying a different resource. The fact that this different resource's state is, in your implementation, derived from the former resource, is an implementation detail that is irrelevant to the client (or the protocol).

As for the fact that, for all resources on your server, the metadata resource's URI is exactly the URI of the former resource + ?meta, this is also an implementation detail. Other implementations may use different patterns, e.g. appending ?view=metadata or .meta or something else. As long as the metadata resource URI is advertised with Link rel="linkset", clients don't need to care or know it in advance, which is much more robust.

So when you write

In TwinPod, we would not make an additional resource

if you are using a different URI for the resource and for its metadata, you are actually making an additional resource.

[elf-pavlik]

I don't find it helpfu to split this conversation across here and #127 since there other one has more comments it should be easy to copy over comments from here and close this one.

[gibsonf1]

If you append ?meta to the URI of a resource, you are essentially identifying a different resource. The fact that this different resource's state is, in your implementation, derived from the former resource, is an implementation detail that is irrelevant to the client (or the protocol).

See #127 (comment) for discussion that a query string on a URI does not a new resource make per spec. For example, if I have paging on a contiainer with ?start=0&limit=20, is this a new resource? No, its the same resource with user requested representation specifics. Similarly the case if ?representation=meta or ?represenation=linkset etc are appended to a URI.