review of ldp-paging

I finally did a careful review.   I see seven issues which are 
substantive and needs to be resolved before LC, and then some editorial 
stuff that could be handled later.

Substantive Issues
============

1. server must not initiate paging

See my email 
http://lists.w3.org/Archives/Public/public-ldp-comments/2014Jul/0002.html

I know I argued for it, but after more thought, I think "server must not 
initiate paging" is too strong, since (as we say elsewhere in the 
document) the server may simply be unable to handle some resource 
without paging.     Instead I suggest we say server SHOULD NOT initiate 
paging, or should treat the lack of paging headers as if a VERY LARGE 
page size were requested (and thus no paging will be done unless they 
have a very large container).

I don't love this answer either, but thinking about my own servers, 
if/when they have a billion-entry container, what are they going to 
do?   I might try to stream it slowly to the client, but I'm not sure 
that's a great idea either, for anyone.    Probably I'd say the server 
default page size is like a 1-10 million triples.

2. rel=canonical

Reading http://tools.ietf.org/html/rfc6596 I'm fine with 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 
that intended as an inverse property to 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.

3. return=representation

I'm not sure about this -- just bookmarking the comment from Greg McFall
http://lists.w3.org/Archives/Public/public-ldp-comments/2014Jul/0000.html

4. adding at the end

I think I pointed this out earlier: 6.2.2.8 says servers SHOULD only add 
pages to the end.  Can we add, "unless some other ordering is signalled, 
such as with containerSortCritera"

5. location and binding of sort criteria triples

Sorry if I'm coming late to this party.   I was surprised by Example 17.

I'd expect the ldp:containerSortCriteria to be in a Link header, sent 
along with the representation of each in-sequence page, to say what the 
sort criteria is for that sequence.

It would be a hash link to something on some page (possibly the 
in-sequence page in question, but not normally, as that seems like a 
corruption of the data) which actually enumerates and describes the 
containerSortCriteria.

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 
way to request the sort criteria it would like.

Some servers might have a standard list of all available sort criteria, 
so they (or clients) can just point to options on that page.    Or 
servers could dynamically generate the given page from information 
embedded in the URI.   Clients could set up a page in advance, or use 
some service (maybe on this server, maybe on a different one) to 
dynamically generate the given page from information embedded in the 
URI, using the convention they know.

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, 
where it's just the client requesting it, so it has no normative weight.

6. paging container as another kind of container

As per discussion point in 7.2, let's not have LDPPCs be a thing. 
Instead, as the text seems to say, let's just say when an LDPPS is 
serving an LDPC, it does such and such.

7. html5 reference

Maybe this is just a typo, but right now we have HTML5 as a *normative* 
reference, which means we'll be stuck behind the HTML5 process (unless 
we basically petition for an exception).   In this case, I think we're 
fine just using RFC 5988 as our normative reference.


Editorial Issues
=========

(running out of time before the meeting, so I'll keep this short)

1. Redundancy

There are several points where text is repeated, like about how forward 
doesn't mean forward, or in section 4, the explanations of the 
headers.   That's painful to read, and error prone, because my eyes 
glaze over, and if you're saying something different somewhere inside 
the repeated text, I wont see it.

2. Feedback points

Obviously there are various notes that should come out before 
publication.   Are there some you think should still be left in?

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.   It's also confusing, 
because you use the word "chunk" very nearby with a different meaning.

4. Typos

Given the time, I'll send these later.

Received on Monday, 21 July 2014 13:53:22 UTC