- From: Tomasz Pluskiewicz <tomasz@t-code.pl>
- Date: Thu, 11 Feb 2016 09:19:11 +0000
- To: "Markus Lanthaler" <markus.lanthaler@gmx.net>, public-hydra@w3.org
February 10 2016 10:57 PM, "Markus Lanthaler" <markus.lanthaler@gmx.net> wrote: > 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) Is your point. If counting members is an issue I would include two separate properties: * totalItems, which, as name implies, denotes total items across all pages * items, which is the number of members on current page These would fit a common pager summary like "showing {items} of {totalItems} things". >>>>> 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. My rationale was that with view and view template separated it's easier for the client to determine that current resource is a view by simply checking the existence of that relation. A separate property for view would make it trivially possible to @reverse so that JSON-LD root becomes the view itself. With views and templates mixed, that would be awkward. Please see the examples I created on the wiki [1]. Also I grow more convinced that the view (as separated from view templates) should be defined as having a strict cardinality of 1. When you get a view, you should get that view or be redirected. Returning multiple views seems counterintuitive to me. Again if that were true, it wouldn't be easily enforced/verified with views and templates mixed.
Received on Thursday, 11 February 2016 09:19:54 UTC