|
If you were logged in you would be able to see more operations.
|
|
|
| Proposal: |
Remove the hasMoreItems from the schema. State on feed resources: If more items are available than contained in the feed returned, a link with the relation next MUST be included in the feed.
In changes collection, state:
if the next page of the changes does not exist yet, the link relation next MAY be available. If the next link relation is not available, the client should revisit the feed in the future and look for new items and the next link relation.
Remove the hasMoreItems from the schema. State on feed resources: If more items are available than contained in the feed returned, a link with the relation next MUST be included in the feed.
In changes collection, state:
if the next page of the changes does not exist yet, the link relation next MAY be available. If the next link relation is not available, the client should revisit the feed in the future and look for new items and the next link relation.
|
|
Why do paged feeds use the hasMoreItems element (from the schema)? The AtomPub rfc says this:
"For this reason, servers MAY respond to Collection GET requests with a Feed Document containing a partial list of the Collection's members, and a link to the next partial list feed, if it exists."
I believe this means that the link for next will not be present if there are no more items to be retrieved.
|
|
Description
|
Why do paged feeds use the hasMoreItems element (from the schema)? The AtomPub rfc says this:
"For this reason, servers MAY respond to Collection GET requests with a Feed Document containing a partial list of the Collection's members, and a link to the next partial list feed, if it exists."
I believe this means that the link for next will not be present if there are no more items to be retrieved. |
Show » |
|
Bug
Closed
Major
hasMoreItems element in schema is redundant
If the tc wants to use the link next as signaling, then that is okay with me too. We would have to solve the unified search case then.