Re: reviewing SHOULD and MUST in LDP paging

On Tue, Jul 16, 2013 at 10:14 AM, Ted Thibodeau Jr <
tthibodeau@openlinksw.com> wrote:

>
> On Jul 16, 2013, at 07:31 AM, Steve Speicher wrote:
>
> >
> > On Mon, Jul 15, 2013 at 5:45 PM, Ted Thibodeau Jr <
> tthibodeau@openlinksw.com> wrote:
> >> Regarding "4.9.2 HTTP GET"
> >> at
> >
> > <https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpr-PagingGET>
> >
> >> 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".
> > I'm not seeing this problem.  Perhaps you had an early or cached copy.
>  Do you still see these problems?
>
> These two have been corrected since my review.
>
>
> >> 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
> >
> > Likewise, I'm not seeing these.
>
> These remain.  The end of 4.9.2.4 is "such that:" which should
> lead into bullets or otherwise more deeply nested sections, so
> there's a definite end to that requirement list, which I believe
> to be all three subsections that currently follow within 4.9.2
> (i.e., the current 4.9.2.5 to 4.9.2.7).
>
> I see now, I just removed ", such that:" and replaced with "." from
4.9.2.4 which seems fine (instead of nesting .5-.7).  This was the same
comment John Arwe had made yesterday.

Thanks for pointing it out.

- Steve Speicher



> >> 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>
> >>       .
> >>
> > ======
> > These all seem reasonable to me.
>
> I hope that clarifies...
>
> 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
>                              //              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
>
>
>
>
>
>
>
>