Specify Container representation to be compound representation

[damooo]

This is an alternate to #86 to enable same use case: User controlled free-form representation for containers, enabling proper HATEOS when used with hypermedia. I request WG to seriously evaluate this requirement.

RFC 2387 defines multipart/related mimetype to enable transferring resource state through a compound representation. When resource's abstract data model is compound of multiple parts each having disparate data model.

Thus container's state can be modelled as compound of (server-managed containment index + user-controlled part) .

• At the time of container creation, user will only attach user controlled part (possibly empty) in message body, just like any other resource representation. Server creates the container, and effective primary representation is set to compound of user-supplied part and server-managed lws+json index.

• in GET response, use conneg to select whatever representation part.

• optionally specify Prefer header values as container-index, user-provided, or like. Thus client can chose which part to get.

• When no Accept or Prefer header is passed, can deliver compound representation with multipart/related. Or can leave to server's discretion.

If #86 is not plausible, this proposal aligns with existing direction of the spec, and just generalizes it using existing standards.

[acoburn]

@damooo thank you for opening this issue and the related #86

Section 9.1 of the current editor's draft describes the role of metadata resources in LWS. This section is primarily focused on metadata that is expressed as link headers, and while that is an important part how metadata is expressed and managed in LWS, there is (as is pointed out in #86) a need to be able to express additional metadata that may not be appropriate for link headers.

A simple example is a "title" or a "description". Link headers work well when linking resources to URIs, but this type of header is invalid:

Link: <The title of my container>; rel="http://purl.org/dc/terms/title"

When the WG discussed the role of metadata last fall at the Face-to-face meeting, there was discussion of two types of client-supplied metadata attached to resources.

The first type is what you see currently in the specification in the form of client-supplied link headers. The second type (which you describe as auxiliary resources in #86) builds on that first type but is currently not specified in the protocol text.

Here is one way that second type of client-supplied metadata could work:

First, assume you have a container at /data/. When performing a GET or HEAD operation on that container, a link header would point a client at a description resource:

Link: </data/.meta>; rel="describedby"; type="text/turtle"

Strictly speaking, any specification building on LWS could define specific requirements for these describedby resources without LWS needing to define anything, though providing some recommendations at the LWS layer would lead to better interoperability.

In my opinion, there are two things that could be added to LWS to be more clear about metadata and how clients interact with that metadata.

First, a better terminology section that has clearer definitions of metadata and the various types of metadata. This is already identified in #27 and needs to be done regardless.

Second, I would be in favor of augmenting the current metadata section to explain how description resources would work -- this would apply to both containers and non-containers: a client may want to add arbitrary metadata to a JPEG image, for instance.

I am not particularly fond of the specific suggestion in this issue related to compound resources (both server and client managed data combined into a single resource). Solid allows this today with containers, and there are plenty of challenges with this, especially related to how concurrency controls work in this context. I do not believe that LWS should necessarily prohibit such behavior, but I would not be in favor of specifying that -- I would be much more in favor of describing how auxiliary metadata resources work.

[damooo]

@acoburn Thanks for the reply.

Servers are allowed to support this optionally, But "clients" can not make interoperable model decisions. I am closing this issue, and continuing at #86 articulating the particular reason why spec should factor out server managed data to separate resource, and leave all resources open for arbitrary client chosen representations with uniform interaction model.