Re: LDP Minutes for 11 August 2014

Jeepers, I'm flying during one meeting, and oy.


EricP: wrt http://www.w3.org/2012/ldp/track/actions/147 I'm a reader + 
purely vicarious author, not an attendee; you'll get more informed answers 
from ErikW (in our own WG) or James Snell (IBM - [1] author) than me when 
it comes to IETF mechanics.  Or Yves in W3C I'd guess; or mnot who you 
were already corresponding with last month.


When I saw Greg's responses today, my first reaction was "oh he thinks 
we're doing inlining"; that's a situation where (depending upon the size 
of the inlined members) counting triples gives one a vastly different 
result than counting members.  It doesn't appear from the minutes that 
anyone else drew similar conclusions (or indeed that it was discussed at 
all).  I don't really worry about the "container as lots of 
non-membership/containership triples" case, in the sense of "fine, if you 
don't like the triples on this page then get the next one" and/or "that's 
what Prefer: return=representation; omit=\"
http://www.w3.org/ns/ldp#PreferMinimalContainer\" is for".  As Steve said, 
"triples" is a good approximation for "members" in most cases, and all the 
more so when the omit-minimal preference is respected.


wrt https://www.w3.org/2013/meeting/ldp/2014-08-11#resolution_3 part 2 
(new units) 
... trivial + clearly our purview
I've always believed different units are most sensible for different use 
cases.  Most of our UI people (historically, doing tables in one/another 
form) want to count rows (what LDP calls members, in the context of an 
LDPC); for our anticipated programmatic uses of paging (not mobile), 
triples is good enough.  I don't see any discussion to indicate 
requirements on servers support the new ones, which I interpret as May.


wrt https://www.w3.org/2013/meeting/ldp/2014-08-11#resolution_3 part 1 
(tie breaker for multiple units)

My read is that this is against the spirit of RFC 7240 [1], although not 
that I can see the letter.  7240 says that the tie breaker is "Should use 
first" ... for preferences (i.e. in our case for return=representation, 
which is the Preference; pagesize is a Preference Parameter), regardless 
of whether this occurs via multiple headers or via duplicate preference 
specification (7240 defines an equivalence relation between the two 
syntaxes).  As far as I can see it is silent on preference *parameters*. 
Recall that the 2119 definition of Should [2] has a higher threshold than 
May, so if we're going to be different we should (heh) have good reason. 

Does LDP have a compelling reason to be handle this case differently than 
its normative reference handles a very similar-looking case?  I don't see 
anything in the minutes to indicate there is one, or that it was even 
known to differ from 7240.  It comes across as an "oh yeah we need to 
handle this corner case too now", which is debatable (since we allowed 
extensions, we already had the case to either specify or be silent on) and 
could easily have been decided absent awareness of the "conflict" with 
7240.  Note that in LDP 7.2.2.3 [3] we relied on [1] for an analogous 
case.

Sandro asserts "logical choice is the stop at the first limit the server 
hits", which I think is true *if you're the client*.  As a server using 
existing tooling like Jena for serialization, "ow my code" that's a whole 
new level of pain.


wrt https://www.w3.org/2013/meeting/ldp/2014-08-11#resolution_2 (client 
can send >1 pagesize)

The existing syntax BNF would not allow what I suspect people intended
        Prefer: return=representation; pagesize="5 triples; 15 smeenorbs"
or more generally
        Prefer: return=representation; pagesize="5 triples ..."
Unless ... is whitespace.

I think the only way to do so today is to send multiple copies of the 
parameter, e.g. 
        Prefer: return=representation; pagesize="5 triples"; pagesize="15 
smeenorbs"
which gets me back to "My read is that this is against the spirit of RFC 
7240 [1]..."
It's reasonable since we define the syntax, and since [1] appears to be 
silent on the question, to define what happens in this case... which, 
given how late in the game it comes up, makes it sound like a corner case 
again.  If that's how the WG sees it, we'd appear incrementally less D&D 
to re-use 7240 again IMO.


wrt Sandro's query about the nose cone reference, in short it means that 
all that truly is needed [insert usual scope/opinion qualifications] for 
"it" to function is finished; the rest (polishing) might make it look 
nicer however is unlikely to make any noticeable functional difference in 
'it'.  By far the closest match on the first page of search results 
asserts the origin as being "in the IBM lab's" (sic) [4].  In spirit it 
echoes the latter part of Alexandrei's "+0 ship it!" comment.


[1] http://tools.ietf.org/html/rfc7240 ... 
http://tools.ietf.org/html/rfc7240#page-4 bottom for the multiple 
same-preference case.
[2] http://tools.ietf.org/html/rfc2119
[3] http://www.w3.org/TR/ldp/#prefer-parameters
[4] http://bluedeckshoe.com/2012/08/18/stop-polishing-nose-cones/

Best Regards, John

Voice US 845-435-9470  BluePages
Cloud and Smarter Infrastructure OSLC Lead