Stricter specifications for pagination of Collections and OrderedCollections

[stevebate]

@yvolk

Reading the spec: " The Update activity is used when updating an already existing object. The side effect of this is that the object MUST be modified to reflect the new structure as defined in the update activity…"
For me this means that each “Update activity” MUST contain information enough to modify (update) current version of the target object. Hence it cannot simply refer to that object.

An example of what I’m suggesting (outbox, partial update):

{
  "id": "https://example.test/update-1",
  "type": "Update",
  "object": {
    "name": "My added name",
    "content": "My updated content",
    "summary": null
  },
  "target": "https://example.test/object-1"
}

This activity instructs the server to apply the update (the direct “object”, an anonymous resource) to the indirect “target” object. It’s consistent with the quotes above and it has an advantage over:

{
  "id": "https://example.test/update-1",
  "type": "Update",
  "object": {
    "id": "https://example.test/object-1",
    "name": "My added name",
    "content": "My updated content",
    "summary": null
  }
}

because the linked data integrity is not broken with the overloading of the semantics of an “id” property to be a “target” reference. In the second example, the IRI “https://example.test/object-1” is associated with two different objects: the one in the Update activity and the existing object. If you consider the activity as part of a linked data (RDF) graph, my point may be more clear.

@yvolk

That “current version” may also be cached by a Client app, for example, so a Client app could apply the same update AND retain the change history, if it’s needed.

Yes, but those are client-specific implementation details outside the scope of the AP specification.