Re: Client preferences

John et al.,

Your response is satisfactory.  Using the page-size parameter as the signal
addresses my concern.

But it highlights another minor concern.  The current draft specifies
'rdf-triples' as the only standard unit.  This is not a particularly useful
unit when paging through a container.  I suspect that most clients would
prefer to specify the number of 'resources' from the container rather than
the number of triples.  It is possible to handle this preference using
extension units so I consider the current draft to be satisfactory, but it
would be better if 'resources' was defined as a standard unit.

Regards,
Greg



On Mon, Jul 28, 2014 at 2:41 PM, John Arwe <johnarwe@us.ibm.com> wrote:

> Greg, the working group discussed this comment on today's call.
>
> The intent of the draft is that the "client supports LDP paging" signal is
> conveyed not merely by the presence of Prefer: return=representation, which
> might be used for other things, but in particular by the presence of a
> page-size parameter (which is newly defined by LDP Paging) on that
> preference.
>
> I just made updates to the editor's draft at [1], changeset [2] to clarify
> that.
>
>
> With respect to the other part of your question, if the header is absent
> (or has just Prefer: return=representation, no page-size parameter) then
> there the server has a choice to make.  Apropos your other comment [3], the
> draft you reviewed (6.2.17 Must Not) requires the server to either serve
> the entire resource (unpaged) or reject the request.  Most servers would
> probably choose a 4xx status code for the rejection case, if the resource
> in question would never be served as paged, although in theory 5xx could be
> used if the server dynamically based its decision on things like server
> load.
>
> If this addresses your questions to your satisfaction, or not, please
> respond to that effect on the list.  In the "or not" case, if you have any
> specific changes that would satisfy you by all means supply them as input.
>  The working group will be reviewing in parallel as well, so it is possible
> that this will still evolve; in the case of substantive change, we'll have
> to ask you to take another look, but that seems unlikely.
>
>
>
> On the same working group call, the working group endorsed Sandro's
> initial response to change 6.2.17 to a SHOULD NOT, for the reasons he
> articulated.  I'll respond to that thread separately once the associated
> changes are live in the editor's draft.
>
>
>
> [1] https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-paging.html
> [2] https://dvcs.w3.org/hg/ldpwg/rev/492ad8a031b9
> [3]
> http://lists.w3.org/Archives/Public/public-ldp-comments/2014Jul/0001.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
>
>