Re: Issue-34 Back_to_Basics proposal

hello all.

On 2013-02-28 00:14 , "Roger Menday" <Roger.Menday@uk.fujitsu.com> wrote:
>I am ultimately trying to argue for something similar to that, yes.
>But, I am building it up in small pieces :)
>So, first, I am trying to build up a case for every predicate being
>treated the same way.

in the use cases we have, we have a clear distinction between "protocol
data" (what's defined by the protocol) and this is what you often want to
see in listings of collections. our services even have filtering
capabilities on top of these, but since they're well-known (defined by the
protocol), these filters themselves can be built and exposed based on the
protocol model.

for non-protocol data, we often restrict visibility to GET requests on the
entries themselves, because (as have been pointed out before) entries can
have large amounts of non-protocol entry metadata attached to them. so
when you GET the entry, you GET the full set of metadata by default.
GETting the entry's content then is yet another matter. it maybe be
embedded or linked, but that's based on how the entry was created. we
don't support changing this (asking that an embedded entry is served with
a link to the content, or asking that linked content is served as
embedded), because then we'd run into serious identity problems.

the reason is that when entries with embedded contents are created, the
content itself does not have identity: the only URI known is that of the
entry that was created as a result of POSTing the entry with embedded
content. on the other hand, when linked entries are created, the content
by definition does have a separate identity (the URI that the content link
refers to), and we want to maintain that other identity.

cheers,

dret.

Received on Thursday, 28 February 2013 09:56:44 UTC