Re: reviewing SHOULD and MUST in LDP paging

On Tue, Jul 16, 2013 at 2:50 AM, Miel Vander Sande <
miel.vandersande@ugent.be> wrote:

> Minor addition: I would like to suggest moving the line of
> https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#http-head
>
> 4.6.2 LDPR servers *must* support the HTTP response headers defined in section
> 4.8 <https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpr-HTTP_OPTIONS>
> .
>
> to the GET section
> https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpr-HTTP_GET
>
> since the headers in HEAD have to be equivalent with GET, it's clearer
> this way
>

Agree, made the change.

Specifically, moved 4.7.2 (from HEAD) to 4.3.2 (GET), shifted rest of GET
section by one

Thanks,
Steve Speicher


> Kind regards,
>
> Miel Vander Sande
> Researcher Semantic Web - Linked Open Data
> Multimedia Lab
> Ghent University - iMinds
> Faculty of Engineering
> Department of Electronics and Information Systems
>
> Gaston Crommenlaan 8 bus 201,
> B-9050 Ledeberg-Ghent, Belgium
> T: +32 9 33 14893
>
>
>
> On 15 Jul 2013, at 23:45, Ted Thibodeau Jr wrote:
>
> All --
>
> Regarding "4.9.2 HTTP GET"
> at
> <https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#http-post-1>
>
> Following comments use the renumbering which came after
> today's call...
>
> a. In 4.9.2.1  and 4.9.2.2, "section 4.8" should change to
>   "section 4.9".
>
> b. subsections 4.9.2.5 through 4.9.2.7 should be nested one
>   deeper -- i.e., renumbered to 4.9.2.4.1 through 4.9.2.4.3
>
> c. I think excerpting the relevant triples from the complete
>   example in 4.9, under each sub-section, will help *greatly*
>   in comprehension and correct adoption.  Also, if we're going
>   to mandate an "rdf:type" predicate, then any examples should
>   display that -- not the sugared "a" predicate.
>
> d. The mix of MUST and SHOULD definitely feels off in these
>   three subsections, which I think is due to their ordering,
>   not to any of these MUST/SHOULD being incorrect.  I suggest
>   the following substitution for the current 4.9.2.5 through
>   4.9.2.7 --
>
> ======
> 4.9.2.4.1  The page resource representation MUST have one triple
>         with the subject of the page, predicate of ldp:nextPage
>         and object being the URL for the subsequent page.
>
>   <http://example.org/customer-relations?firstPage>
>         ldp:nextPage  <http://example.org/customer-relations?p=2>
>      .
>
> 4.9.2.4.2  The last page resource representation MUST have one
>           triple with the subject of the last page, predicate
>           of ldp:nextPage and object being rdf:nil.
>
>   <http://example.org/customer-relations?p=2>
>         ldp:nextPage  rdf:nil
>      .
>
> 4.9.2.4.3  Given the presence of the ldp:nextPage triples
>           described above, an LDP client could infer that
>           each page containing such *is* in fact an ldp:Page,
>           but this does not guarantee the URI of the resource
>           which description is being paged over.  Therefore,
>           to lower the burden on LDP clients and increase data
>           fidelity, the page resource representation SHOULD
>           include two additional triples: one to indicate its
>           type, whose subject is the URL of the page, whose
>           predicate is rdf:type and object is ldp:Page; and
>           one to indicate the LDPR which description is being
>           paged, whose subject is the URL of the page, predicate
>           is ldp:pageOf, and object is the URL of the LDPR.
>
>   <http://example.org/customer-relations?firstPage>
>           rdf:type  ldp:Page
>      ;  ldp:pageOf  <http://example.org/customer-relations>
>      .
>
> ======
>
>
> Regards,
>
> Ted
>
>
> --
> A: Yes.                      http://www.guckes.net/faq/attribution.html
> | Q: Are you sure?
> | | A: Because it reverses the logical flow of conversation.
> | | | Q: Why is top posting frowned upon?
>
> Ted Thibodeau, Jr.           //               voice +1-781-273-0900 x32
> Senior Support & Evangelism  //        mailto:tthibodeau@openlinksw.com<tthibodeau@openlinksw.com>
>                             //              http://twitter.com/TallTed
> OpenLink Software, Inc.      //              http://www.openlinksw.com/
>         10 Burlington Mall Road, Suite 265, Burlington MA 01803
>     Weblog   -- http://www.openlinksw.com/blogs/
>     LinkedIn -- http://www.linkedin.com/company/openlink-software/
>     Twitter  -- http://twitter.com/OpenLink
>     Google+  -- http://plus.google.com/100570109519069333827/
>     Facebook -- http://www.facebook.com/OpenLinkSoftware
> Universal Data Access, Integration, and Management Technology Providers
>
>
>
>
>
>
>
>
>