ISSUE-56/ISSUE-57

hello all.

arnaud's effort to reduce the number of open issues deserves some support,
so i'll try to tackle some of those that look a bit RESTish to me.
ISSUE-56 and ISSUE-57 are very closely related; they both address the
issue how some client is able, when just starting with a random URI it has
been handed by somebody, to figure out it is actually talking to an LDP
service, and can expect to successfully apply the LDP processing model to
get things done.

we have discussed possible scenarios for this kind of discovery already.
here a brief summary (and very incomplete pro/con lists):

- media type: it would be possible to mint an LDP media type, and then
clients would know because of the media type of the response.

-- pro: best visibility on the web level.
-- con: not the way media types are used with RDF today.

- profiles: instead of minting a media type, it would be possible to mint
an LDP profile URI and signal it as media type parameter. however, this
only works if RDF media types actually supported such a parameter, which
they currently don't.

-- pro: still visible on the media type level.-- con: not supported by
current RDF media type registrations.

- properties: LDP resources could always expose their types, so that
clients can inspect the type and act on that. this works, but currently
the spec does not require that resources expose their types.

-- pro: works without requiring any additional mechanisms.
-- con: not visible/accessible on the web level any more.

iff we have a model that uses any of those mechanisms, then we can define
affordances based on the type. we can define them implicitly or
explicitly. if they are implicit, then clients just need to figure out
they're talking to an LDP resource, and then can start using those rules
(PUT for updating a LDPR, POST for adding to a LDPC). if we have explicit
affordances, then clients would expect to find links that they can
interact with as clearly labeled links in the representation (such as
atompub's "edit" link that really only serves the purpose of potentially
decoupling the "read" from the "write" identity of a resource, if that is
what a service wants to do).

afaict, step #1 to get this done is to settle on one of the three variants
listed above. i may be wrong, but from the REST point of view, these are
the options we have, and if we're not supporting one of them, there is no
way we can close issues such as 56 and 57. if anybody thinks this list
should be extended, i'd be curious to hear what else could be done so that
clients actually can figure out what they are interacting with.

cheers,

dret.

Received on Friday, 31 May 2013 00:11:33 UTC