A conforming Fedora server is a conforming [[!LDP]] 1.0 server except where described in this document that also follows the rules defined by Fedora in , - , , , and . + , , , and .
- This section defines when messages are emitted by a Fedora - implementation, the minimal set of data contained in those messages and how - those data are serialized. These messages may occur synchronously or asynchronously - with the API operations that cause them to be emitted. They are typically used to - support external integrations. The structure of these messages draws upon the + This section defines when notifications are made available by a Fedora + implementation, the minimal set of data contained in these notifications and how + the data are serialized. Notifications may be emitted synchronously or asynchronously + with the API operations that cause them to be emitted. These notifications are typically + used to support external integrations. The structure of these notifications draws upon the existing [[activitystreams-core]] and [[ldn]] specifications. - An implementation is free to choose from any messaging technology so long as - the messages conform to what is described in the following sections. -
-- Any operation that causes the state of a resource to durably change MUST cause a - message to be emitted with a corresponding resource identifier. -
-- A failed operation (HTTP 4xx or 5xx) MUST NOT emit any messages. -
-- Messages MUST NOT be emitted until after any changes have been persisted to durable storage. + An implementation is free to choose from any transport technology so long as + the notifications conform to what is described in the following sections.
- Repository start, stop and configuration change operations MAY cause a message to be emitted.
+ Implementers should be aware that some operations cause multiple resources to change.
+ In these cases, there will be a corresponding notification describing each of the changes.
+ This is especially true for changes to containment or membership triples. This is also true
+ if a DELETE operation triggers changes in any contained resources.
- Any operation on an LDPR that results in a change to the containment or membership - triples of a distinct other LDPR MUST also trigger an event for that other LDPR. + Consumers of these notifications should not expect a strict ordering of + the events reported therein: the fact that a notification for Event A is received before + a notification for Event B should not imply that Event A occurred before Event B. + Implementations may choose to make further guarantees about ordering.
- Any operation that causes contained resources to change MUST trigger corresponding - events for those resources. For example, deleting a parent resource and thereby - changing the state of its child resources MUST result in corresponding events for - each of the contained child resources. -
-- Non-normative: consumers of these messages should not expect a strict ordering of - the events reported therein: the fact that a message for Event A is received before - a message for Event B should not imply that Event A occurred before Event B. - Implementations may choose to make further guarantees about ordering. + According to the [[activitystreams-core]] specification, it is possible to collect multiple + events into a single notification. This specification makes no restriction on the use of + activity stream collections.
- Emitted events MUST contain exactly one value for each of the following elements: -
-- A message MUST contain at least one value for the event type. Event types SHOULD be drawn - from the [[!activitystreams-vocabulary]]. -
-- A message SHOULD contain at least one value for the agent operating on the resource. -
-- A message SHOULD contain a collection of RDF types corresponding to the resource that - was changed. + For every resource whose state is changed as a result of an HTTP operation, + there MUST be a corresponding notification made available describing that change.
+
- If the corresponding LDPR includes an ldp:inbox, the location of
- that inbox SHOULD be included in the message.
+ The notification serialization MUST conform to the [[!activitystreams-core]] specification.
- Messages MAY contain a timestamp marking the time the resource was added/modified/deleted. + Wherever possible, data SHOULD be expressed using the [[!activitystreams-vocabulary]].
- Messages SHOULD NOT contain the entire content of repository resources. + Each event described by a notification MUST contain:
-- The message body serialization MUST conform to the [[!activitystreams-core]] specification. + Each event described by a notification SHOULD contain:
+ldp:inbox for the resource that was changed, if such an inbox link exists- Wherever possible, data SHOULD be expressed using the [[!activitystreams-vocabulary]]. + Notifications SHOULD NOT contain the entire content of repository resources.
{
@@ -827,8 +805,8 @@ A minimal message
{