Re: review of ldp-paging

On 07/21/2014 12:47 PM, John Arwe wrote:
> > 1. server must not initiate paging
> > ...     Instead I suggest we say server SHOULD NOT initiate
>
> Fine with me, brings it into line w/ the printable version of my 
> initial reaction.
>
> > 2. rel=canonical
> > so let's take out the note?
> > I do see ldp:pageOf used in Example 17.  I assume that's obsolete? 
> Or is
>
> Both were done (at least) 5 days ago.  Makes me wonder if you saw [1].

Apparently I was tired enough last night to be reviewing an older 
printout by mistake.

I'll take another look.

        :-(

       - s

>
> > 2. rel=canonical
> > Do we need an IRI for rel=canonical?   Markus and I are still 
> talking to
> > Mark Nottingham about IRIs for rel's, offlist.
>
> LDP Paging does not need one.
> Since I'm not sure of the scope of the offline discussion, I'm not 
> able to meaningfully answer otherwise.  If you're heading toward the 
> detente I outlined in [2] paragraph 2, you would not need any special 
> handling for any registered rel= value.
>
> > 3. return=representation
>
> Last time around, I thought the guidance from our chair was to resist 
> the temptation to respond to public-comments messages in advance of WG 
> discussion.  I assumed that discussion would take place on the 
> just-ended call.  Were I to do so, it would be along the lines of: I 
> don't think we're hijacking anything.  In fact, we discussed our use 
> of it months ago with the principal RFC author who had no such 
> reaction.  The commenter seems to have over-generalized when reading 
> that it's the presence of 'return=representation' as the LDP Paging 
> client signal - it's not, it's the presence of the pagesize preference 
> parameter.  If a client sends "Prefer: return=representation", no LDP 
> Paging server should take that as signalling a client's support for 
> LDP Paging.  'Prefer: return=representation; pagesize="..."' is the 
> functional minimum for the signal.
>
> > 4. adding at the end
> > pages to the end.  Can we add, "unless some other ordering is 
> signalled,
>
> I never read 4's topic to be connected to sorting - ever, at all; 
> completely orthogonal concerns in my mind.  I thought the point of the 
> constraint on adding pages was to give the client a predictable way to 
> detect if more pages had been added (keep re-fetching last page known 
> to it and looking for either 4xx or link rel='next' to show up in the 
> response).
>
> I agree that makes adding pages into a server-sorted container 
> potentially impossible (in the sense of doing so by adding the 
> rel=next link), but I took that effective constraint as simply a 
> consequence of the functional composition.  If you relax the 
> constraint for sorted containers, for those you're rendering 4's 
> constraint useless; either way you're saying, in effect, that they 
> don't play nice together.  Given that the result is the same, I'm 
> pretty agnostic as to whether we treat that as a "club the baby seal" 
> moment or not.  The more pages in the sequence, the less that allowing 
> pages to be added anywhere helps a client, AFAICS; instead of 
> re-fetching 1 page the client would have to re-fetch all pages in 
> order to 'poll' for new ones, which is not meaningfully different from 
> traversing anew.
>
>
> > 5. location and binding of sort criteria triples
>
> I think it's been that way since the Submission pretty much (FWIW).
>
> > 5. location and binding of sort criteria triples
> > I'd expect the ldp:containerSortCriteria to be in a Link header, sent
>
> I want to be clear about what you're expecting, since I can see 
> multiple interpretations [waves to Kingsley].  At one point in some 
> distant past I toyed with the idea of putting all of the info in that 
> section into Link headers, ran into "the" ordering problem (how to 
> express the sequence of primary, secondary, ... sort keys when IIRC 
> Link headers are not ordered), and stopped.  I think you're saying 
> something different however; I think you're saying provide the link to 
> the criteria (ordered set of keys), express that set *in RDF* (not in 
> Link headers), done.  Which I like, partially in the sense of "dammit, 
> Janet, why didn't I think of that variation before?"
>
> > 5. location and binding of sort criteria triples
> > This would make it very easy to support client-selected sort criteria,
> > as the client could just sent this link header itself, on a GET, as a
>
> Indeed, and this is part of why I like it.  My "caching/conneg" 
> antennae are standing at attention, but perhaps it's manageable.
>
> > 5. location and binding of sort criteria triples
> > Frankly, I'd really like to see the bit about clients sending this link
> > header to be in this spec today.   I would be like a prefer header,
>
> Actually making it into a Prefer header parameter, rather than being 
> "like" one, might be a starting point.  Return=representation already 
> carries conneg warnings in the RFC, so at least we'd make things no 
> worse by doing this.  Optimistically, the general Prefer-red ways of 
> handling conneg "issues" may solve everything for us already.
>
> > 6. paging container as another kind of container
>
> IIRC I did this in the changeset related to [1].
>
> > 7. html5 reference
>
> Not a typo - it's the link relations (2 of them IIRC, probably 
> next/prev) via the registry.
> I can change them back to 5988; I think we are free to use its 
> definitions, even if its contents are not the current values in the 
> link relation registry.  It's debatable from a process perspective 
> whether or not the latter should be *allowed* to refer to "unfinished" 
> specs of course, but it's not our process either.
>
> > 1. Redundancy
>
> Please verify that what you reviewed matches [1], or that [1] 
> sufficiently Visine's your sore eyes, or be more specific on 
> whatever's left.
>
> > 2. Feedback points
>
> Anything live after [1] I assumed the WG would leave in, minus "Ready 
> for LC?" in the SOTD and the At Risk at 6.2.5.5.  Having just looked, 
> I see no others remaining though.
>
> > 3. Transfer-Encoding: chunked
> > Can we leave out this header from the examples?    As I understand it,
> > the response is not actually chunked, as shown.
>
> As I read the RFC, I don't think one can tell by visual inspection; to 
> be fair, I wasn't using high power on the RFC-oscope when I read it. 
>  It's main allure was that it removed the need to fuss with 
> Content-Length values, honestly.
>
>
> > 3. Transfer-Encoding: chunked
> ...   It's also confusing,
> > because you use the word "chunk" very nearby with a different meaning.
>
> Good point.  Since that's the only place 'chunk' is used for 'page', I 
> was already on the cusp of nuking it.  This tips the scale for me, 
> tossing chunk[s ;-)] is the right thing to do.
>
> > 4. Typos
>
> Well baby seal, see if [1] (or the small delta on that a day later, or 
> Steve's subsequent typo replacements) fixed them before typing them in.
>
>
> BTW, did anyone catch yesterday's mostly final Python broadcast? 
>  Their website was such an abomination I gave up trying to find out 
> which US theaters were showing it.
>
>
> [1] http://lists.w3.org/Archives/Public/public-ldp-wg/2014Jul/0053.html
> [2] http://lists.w3.org/Archives/Public/public-ldp-wg/2014Jul/0037.html
>
> Best Regards, John
>
> Voice US 845-435-9470 BluePages 
> <http://w3.ibm.com/jct03019wt/bluepages/simpleSearch.wss?searchBy=Internet+address&location=All+locations&searchFor=johnarwe> 
>
> Cloud and Smarter Infrastructure OSLC Lead
>