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

([2] makes sense, but I guess we might as well keep the thread separate, 
since LDP doesn't care.)

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

Sorry, I've lost track of which WGs have which policy there.

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

Maybe we could clarify that in the spec and see if that addresses the 
commenter's concern?

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

(see other thread)

> > 5. location and binding of sort criteria triples
>
> I think it's been that way since the Submission pretty much (FWIW).
>

Yes, that's why I apologized for pointing this out so late.     I should 
have said something as soon as we started using Link headers, but I 
didn't look at sorting again.

> > 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?"
>

:-)   Right, exactly.

There would be one Link header, rel=.../containerSortCriteria, on each 
in-sequence page of a paged Container, if the server wanted to 
communicate what ordering it was using in doing that paging.

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

I would expect the containerSortCriteria to be embedded in the URL of 
the in-sequence resource, in which case there's no caching problem.  The 
server kind of needs to do that, because otherwise how else can it 
construct the page?

For example, if the client wants the employee phone book in inverse 
order of date-of-hire, so it can find the recent hires, it would:

      > HEAD /phonebook HTTP/1.1
      > Host: example.com
      > Link: </phonebook-sorting#invDateOfHire> 
rel="http://www.w3.org/ns/ldp/containerSortCriteria"
      ...
      < HTTP/1.1 200 OK
      < Link: 
</phonebook?after=&sort=http://example.com/phonebook-sorting#invDateOfHire> 
rel=first

then it can do a GET on that rel=first link to get the data.   The 
rel=next link out of that page would still have the &sort parameter.

(and yes, it should be %-escaped, in a way I didnt do for this example)

FWIW, the same approach could be used for asking for certain members to 
be selected or certain membership triples to be inlined.

Dereferencing http://example.com/phonebook-sorting#invDateOfHire would 
get the stuff that's in 7.2.1 with containerSortCriterion, 
containerSortOrder, etc.

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

Yeah, I guess Link is understood to be a Response Header, not a Request 
Header.   I don't see anything in 5988 saying anything one way or the 
other, but eg http://en.wikipedia.org/wiki/List_of_HTTP_header_fields 
puts it as a Response Header.

Do you think we could put it in At Risk, as see if IETF folks are okay 
with it, as a Preference?



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

I believe the powers that be are fine with a normative reference to 5988 
but not to HTML5 at this point.

We could ask for an exception re HTML5, but since it's so easy not to 
use it, that's the route I'd be inclined to talk.

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

:-)     +1


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

I can't imagine a better way to spend my Saturday afternoon....? Will try.

       - s

>
> [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
>

Received on Saturday, 26 July 2014 18:41:12 UTC