W3C home > Mailing lists > Public > public-ldp-wg@w3.org > June 2013

Re: Discovery/Affordances

From: Andy Seaborne <andy@apache.org>
Date: Wed, 12 Jun 2013 10:11:31 +0100
Message-ID: <51B83B43.90508@apache.org>
To: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
Hi Arnaud,

On 12/06/13 01:29, Arnaud Le Hors wrote:
> Hi Andy,
>
> Andy Seaborne <andy@apache.org> wrote on 06/11/2013 03:12:09 AM:
>
> > Would the following be an LDP server?
> >
> > A vanilla web server that provides GET, POST, PUT, DELETE, HEAD and 
> eTags.
>
> If you mean by that that the server only implements what's required by 
> the HTTP spec the answer would have to be no. The LDP spec defines a 
> set of additional requirements on top of HTTP that one must comply 
> with to be called an "LDP server".
>
> >
> > In what way is not an LDP-R -only server?  (no -C's)
>
> I believe, as the spec stands, a server must support LDPCs to be 
> compliant. There are various aspects like paging that are optional but 
> I don't think you can pass on the whole LDPC.
>
> Should I take from what you're saying that you think we should have a 
> level of conformance for LDPR-only servers?

Good question - my message was originally in response to the complexity 
seemingly arising.  Is plain-simple HTTP valid interaction?

That said, I wil suggest that either having a level of conformance for 
LDPR-only servers or a explicitly understood reason why such a thing 
isn't helpful would be good.

The lower the barrier to being a compliant LDP server, the more 
widespread they (and clients) will be and the more data that can be 
integrated.

Clearly, there is a tension between being so minimal as to be useless, 
or so minimal that an application has to add a lot of app-specific 
functionality; this risks going round the loop on range of applications 
in scope of the WG.

Is a simple key-value store where the key is a URI and the value being 
graph data an LDP server?  How much more would it take to be one?

     Andy
Received on Wednesday, 12 June 2013 09:12:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:51 UTC