Re: ItemList

Actually, lately I've been thinking that Role is an interesting use for a Collection-like thing. In Hydra a Collection is used to contain relationship statements relating an item with many others sharing a property relationship. Role does something similar, but really for just a single related item.

A CollectionRole could extend Role to allow for a multi-valued property relationship, along with other information such as count and pagination controls.

Marking up social relationships can lead to a large number if values for a given property; this would allow those property relationships to be proxies through a separate CollectionRole located at a different URL.

Gregg Kellogg
Sent from my iPhone

> On Jun 14, 2014, at 12:34 PM, "Markus Lanthaler" <markus.lanthaler@gmx.net> wrote:
> 
>> On 11 Jun 2014 at 00:43, Dan Brickley wrote:
>>> On 10 June 2014 22:36, Markus Lanthaler wrote:
>>> On Tuesday, June 10, 2014 7:36 PM, Dan Brickley wrote:
>>>>>> Re 'numberOfElements' maybe we can find an existing property to
>>>>>> extend?
>>> 
>>> Very minor point but numberOfItems might be better given how the other
>>> properties and the type itself is documented:
>>> 
>>> A list of *items* of any sort...
>>> A single list item...
>>> ListItem
>>> ...
>> 
>> Perhaps, but we also use the word element, i.e. itemListElement.
> 
> True. But actually that's confusing as well IMO. Why not (re-)use "item"? ListItem is basically an indirection/proxy/wrapper for the entity you want to add to the list. It uses "item" to reference that entity. Couldn't we use item directly on ItemList as well? If not, probably it would still be better to use "item" on ItemList and change ListItem's "item" to "value" or something similar.
> 
> 
> [...]
> 
>>> It would also be nice if an example using next and previous would be added as people
>> will probably struggle referencing it both from the ItemList and from a ListItem at the same
>> time if there isn't an example they can copy-paste.
>> 
>> Yes, more example suggestions welcomed.
> 
> I quite like the flexibility of having both next/previous and itemPosition. I just wonder what happens if they contradict each other (caching could easily lead to such situations). Should consumers reject such data? Or should one of the two mechanisms (probably itemPosition) be ignored in such cases?
> 
> 
> --
> Markus Lanthaler
> @markuslanthaler
> 
> 
> 
>

Received on Thursday, 26 June 2014 15:46:13 UTC