- From: Steve Speicher <sspeiche@gmail.com>
- Date: Mon, 16 Jun 2014 09:02:16 -0400
- To: Nandana Mihindukulasooriya <nmihindu@fi.upm.es>
- Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- Message-ID: <CAOUJ7JpD-DiQ92eRibw5L58Mde2u37ZTKRYSmXJhEw0vcwYKvw@mail.gmail.com>
Hi Nandana, On Mon, Jun 16, 2014 at 8:54 AM, Nandana Mihindukulasooriya < nmihindu@fi.upm.es> wrote: > Hi Steve/all, > > On Sat, Mar 29, 2014 at 7:26 PM, Steve Speicher <sspeiche@gmail.com> > wrote: > >> On Fri, Mar 14, 2014 at 3:10 AM, Nandana Mihindukulasooriya < >> nmihindu@fi.upm.es> wrote: >> >>> >>> Also regarding the Link header, in 5.2.1.4 we say 'The notes on the >>> corresponding LDPR constraint apply equally to LDPCs.'. So does this mean a >>> container should always advertise two Link headers, e.g. >>> >>> Link: <http://www.w3.org/ns/ldp#Resource>; rel="type" >>> Link: <http://www.w3.org/ns/ldp#Container>; rel="type" >>> >>> I find it a bit redundant as LDPC is a subclass and always a LDP-RS/LDPR >>> but not an issue. Just wanted to make sure as I don't remember all the >>> discussions on client inference vs overhead. >>> >>> I see no need to repeat these. >> >> - Steve Speicher >> > > As I read the requirements of the spec, I thought both ldp:Resource and > ldp:XContainer headers should be present in the response. But based on the > above comment and a feedback received from Henry, I changed the primer not > to repeat ldp:Resource the header. But now when I check the examples added > in the spec [1], I see those two headers are explicitly present. So shall > we follow the same style in the primer ? > I see no need to repeat #Container entry, though 4.2.1.4 seems pretty clear that it expects #Resource "in all responses made to an LDPR's HTTP Request-URI" [4.2.1.4]. That is why I repeated it. [4.2.1.4]: https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpr-gen-linktypehdr Regards, Steve Speicher > > Best Regards, > Nandana > > [1] - https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpc >
Received on Monday, 16 June 2014 13:02:45 UTC