Re: ldp-ISSUE-41 (Member Attachments): Standard way to manage members with attachments

hello all.

since this also affects ISSUE-37, a brief opinion.

On 2012-11-28 05:52 , "Linked Data Platform (LDP) Working Group Issue
Tracker" <sysbot+tracker@w3.org> wrote:
>When the user retrieves the work order later, they expect a single
>request by default to retrieve the work order plus all attachments.
>When the user updates the work order, e.g. to mark it completed, they
>only want to update the work order proper, not its attachments.
>Users may add/remove/replace attachments to the work order during its
>lifetime.

there's a reason why AtomPub has made the simple choice to have a maximum
of one "attachment" per entry: you can keep things simple, both on the
interaction level (no mime required), and on the logical level. the model
john proposes here introduces highly complex operations on the member
level, and essentially turns a member into a container/collection itself.
only that now, the new requirement is added that complex operations on
that container should also be supported as transactions. is this
requirement recursive? and is the transaction requirement only valid for
the "members that are containers", or for "containers that are just
containers" as well?

i don't want to say this is a bad use case, but i simply want to point out
that this is a fairly complex scenario and resulting requirements, with
many side-effects when it comes to designing interactions and reusing
concepts within the design. deciding whether we want to go this route or
not will be one of the many important decisions we have to make when
deciding on ISSUE-37.

cheers,

dret.

Received on Wednesday, 28 November 2012 17:16:46 UTC