W3C home > Mailing lists > Public > public-ldp-wg@w3.org > October 2012

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

From: Eric Prud'hommeaux <eric@w3.org>
Date: Sun, 21 Oct 2012 18:22:39 -0400
To: Mark Baker <distobj@acm.org>
Cc: Ruben Verborgh <ruben.verborgh@ugent.be>, David Wood <david@3roundstones.com>, "Linked Data Platform (LDP) Working Group" <public-ldp-wg@w3.org>
Message-ID: <20121021222237.GD16561@w3.org>
* Mark Baker <distobj@acm.org> [2012-10-21 17:19-0400]
> On Sun, Oct 21, 2012 at 3:53 PM, Ruben Verborgh <ruben.verborgh@ugent.be> 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
    http://www.w3.org/Protocols/HTTP/ietf-http-ext/draft-frystyk-http-extensions-03

  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
    https://dev.twitter.com/docs/api/1.1/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.
> 

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:17:32 UTC