Re: review of ldp-paging

> 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].

> 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
Cloud and Smarter Infrastructure OSLC Lead