Re: ldp-ISSUE-24 (remain deleted): Should DELETED resources remain deleted? [Linked Data Platform core]

* Mark Baker <> [2012-10-21 17:19-0400]
> On Sun, Oct 21, 2012 at 3:53 PM, Ruben Verborgh <> wrote:
> > Hi Mark,
> >
> >> Nothing else can be promised by servers or expected by clients,
> >> at least without defining HTTP extensions.
> >
> > Why not?
> > Any server is allowed to promise something more.
> Only with an HTTP extension, yes.

I can think of three interpretations of "HTTP extension":

  1 HTTP Extension Framework

  2 Task-specific protocol extensions like WebDav or HTTP Over TLS

  3 Task-specific uses of the protocol such as those that might be
    described by WSDL, WADL or only human-readable documentation, e.g.
    Twitter GET statuses/mentions_timeline

I believe 3 is in line with the LDBP Submission.

> > If the client understands this promise, it can make use of the consequences.
> > If it doesn’t, then it just uses HTTP (and that will work if there’s no contradiction).
> >
> >> As I mentioned before, servers are free to
> >> *do* more, as that's an implementation consideration that HTTP doesn't
> >> generally concern itself with.
> >
> > True, and the LDP spec defines a class of such servers.
> >
> >> But clients cannot *expect* more,
> >> because expectation is defined by the contract alone.
> >
> > They can expect more if they agree this contract is the LDP spec,
> > which is what an BPR client and BPR server will do.
> Only if that contract is explicit in the message(s), and that requires
> an HTTP extension.
> >
> > I’ve tried to summarize the possible options in a yes/no diagram:
> >
> > Currently, can BPR clients talk to BPR servers? Yes.
> > Can generic HTTP clients talk to BPR servers? Yes.
> > Can other RFC2616-compliant intermediaries talk to BPR servers? Yes.
> >
> > Can BPR clients talk to generic RFC2616 servers? No. Should they? No.
> Whoa, that was unexpected. Before I pick apart why that's an awful
> idea, I'd like to ask whether others agree or disagree.

I agree. I'd not expect somone to use firefox to perform a POST to
create a new, e.g. bug report any more than I'd expect them to have
meaningful interactions with any other web service which consumes and
produces machine-readable data.

One could develop a parallel HTML-y interface, replete with POST forms
and hypertext links, and even use conneg to serve it from the same
endpoint. That would be a nice bonus, helping developers get the hang
of the interfaces we're defining, but ultimately we need to write a
spec for the machine interactions.

> > If a client is designed for BPR servers, it can only be expected to work with BPR servers.
> > Unless it's also a generic HTTP client. But then, it will apply the regular HTTP rules
> > for non-BPR resources (otherwise, it’s not a generic HTTP client).
> Oh my ... :(
> Mark.


Received on Sunday, 21 October 2012 22:23:08 UTC