- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Wed, 10 Feb 2016 22:55:57 +0100
- To: <public-hydra@w3.org>
On 9 Feb 2016 at 12:47, Tomasz Pluskiewicz wrote: > February 8 2016 9:46 PM, Markus Lanthaler wrote: >>>> I'm just a bit uneasy about multiple PartialCollectionViews, each with >>>> it's own totalItems. >> >> Yeah, I find that a bit confusing as well but in order to make this >> unambiguous to a machine we need them I guess. > > Do we? Please exaplain My previous mail should hopefully explain my thinking (number of items on the page vs. overall) >>>> I think that there should only be one such view in >>>> a response. >> >> How would you communicate to a client then that the response was not >> only filtered, but that the server also decided to paginate it? > > Does it matter to the client? The client should only care that there are more pages (linked) > and how to possibly construct different views. That's a good point. I have to think a bit more about it but probably you are right. And the fact that there are more pages actually tells that a client already. >>>> Also I'm not sure about mixing both ViewTemplate and View on single >>>> `view` property. >> >> We can certainly split it into two properties but I'm not sure that >> would buy us much. What advantages would you see? > > As a client I wouldn't have to inspect each individual element of 'view' to determine > whether it's a View or a ViewTemplate. Simple as that, Separation of Concerns, and thus > simpler client implementation. You need to check the input anyway, right? But it would make clients that look specifically for views/view templates more efficient as they wouldn't need to filter a set containing both. I'm a bit on the fence on what to optimize for here. The other thing in the back of my mind is the comparison to links/templated links. I wouldn't want to introduce additional link relationship types (properties) in that case either. -- Markus Lanthaler @markuslanthaler
Received on Wednesday, 10 February 2016 21:56:27 UTC