Re: LDP Minutes for 11 August 2014

Hi John,
I can only speak for myself but when it comes to the possibility of having 
the server receive several preferences I thought it was in the form of 
multiple occurrences of the header.

As for the rest, I invite those who pushed for having different units to 
chime in! Sandro?
Thanks.
--
Arnaud  Le Hors - Senior Technical Staff Member, Open Web Standards - IBM 
Software Group


John Arwe/Poughkeepsie/IBM@IBMUS wrote on 08/12/2014 01:00:08 PM:

> From: John Arwe/Poughkeepsie/IBM@IBMUS
> To: "public-ldp-wg@w3.org Working Group" <public-ldp-wg@w3.org>
> Date: 08/12/2014 01:02 PM
> Subject: 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