Solid Notifications Use Cases and Requirements
Editor’s Draft, 2023-10-18
- This version
- https://solid.github.io/notifications-panel/notifications-ucr
- Latest version
- https://solid.github.io/notifications-panel/notifications-ucr
- Created
- Published
- Modified
- Repository
- GitHub
- Language
- English
- License
- MIT License
- Document Status
- Editor’s Draft
- In Reply To
- Solid Origin
- Notifications Panel Charter
- Policy
-
- Rule
- Offer
- Unique Identifier
- https://solid.github.io/notifications-panel/notifications-ucr#document-policy-offer
- Target
- https://solid.github.io/notifications-panel/notifications-ucr
- Permission
-
- Assigner
- W3C Solid Community Group
- Action
Copyright © 2021 W3C Solid Community Group.
Abstract
Solid Notifications Use Cases and Requirements.
Issue: Update Notifications UCR
UCR needs a review/revision. Solution-centric references have no place in a UCR document. issues/76.
Status of This Document
This section describes the status of this document at the time of its publication.
This document was published by the Solid Community Group as an Editor’s Draft. The information in this document is still subject to change. You are invited to contribute any feedback, comments, or questions you might have.
Publication as an Editor’s Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.
Introduction
This section is non-normative.
Motivation...
..
This document is for:
- Technical communicators that want to develop information and media concepts, standards, structures and software tool support.
Terminology
This section is non-normative.
This document defines the following terms. These terms are referenced throughout this document.
- Foo Bar Baz
- Foo Bar Baz...
Use Cases
This section is non-normative.
Immediate Notification of Data Changes
For many clients, it is important to know when a resource state changes. This includes collaborative editing apps, chat apps or any client that expects the underlying data to change frequently based on updates made by others.
Notification of Data Changes on Multiple Resources
Clients might want to know state changes of multiple resources at the same time. For example, an app may simultaneously receive notifications from a container, resource(s) within the container, and/or resource(s) linked to the container.
Amend List of Resources for Notification of Data Changes
Clients might want to amend the list of resources from which they receive notifications of data change. This allows the client to respond to modifications made to a container, such as a resource being created or removed from within it.
Frequency of Notifications
Sometimes a client doesn't need to be alerted for every change. If a client only needs infrequent updates (for example, every 5 minutes), it should be possible to avoid floods of data that might otherwise place a higher burden on the client application. Ideally, a client should be able to define what that aggregation window would be: for some clients, 10 seconds might be appropriate; for others, several minutes might be more appropriate.
Filtered Notifications
Certain categories of notifications may be more or less interesting to clients. For example, a client may not care about UPDATE operations or may only care about notifications for resources of certain types.
Time-bound Subscriptions
Occasionally, a client only needs a subscription to be in effect for a limited period of time. While a client may easily close a WebSocket itself, subscriptions for other, more asynchronous forms of notifications, such as LDN alerts or WebHook operations, may be more difficult to terminate.
Lost Update Notifications
For WebSockets and subscriptions that rely on an active, live connection to a notification server, the subscription channel needs to make sure that clients do not miss notifications in the event of a dropped connection.
- Requirements
- Create Events
- Update Events
- Delete Events
- Authorization
Capability Discovery
A given Solid Notification server may support certain technologies (e.g., WebSockets and LDN) but not others (e.g., EventSource and WebSub). Likewise, a client may not support the same set of technologies that are implemented by a server. As such, there needs to be a mechanism for clients and servers to agree on a mutually supported subscription type. In addition to simply determining the set of protocols that work for client and server, there may be particular features (e.g., notification aggregation, notification filtering) that are required by the client. This could be used to further filter the protocol selection.
- Requirements
- Capability Discovery
Requirements
This section is non-normative.
This section lists the functional and non-functional requirements arising from the use-cases catalogued in this document. Specific requirements that have been de-prioritized or rejected have been left in the document for completeness, but are shown as struck out.
The use cases and their requirements are tabulated below, followed by a definition of each requirement.
Use Case | Functional Requirements | Non-Functional Requirements | |||||||
---|---|---|---|---|---|---|---|---|---|
F1 | F2 | F3 | F4 | F5 | F6 | F7 | F8 | NF1 | |
Immediate Notification of Data Changes | ✔ | ✔ | ✔ | ⌙ | ✔ | ⌙ | ✔ | ⌙ | ⌙ |
Notification of Data Changes on Multiple Resources | ✔ | ✔ | ✔ | ⌙ | ✔ | ⌙ | ✔ | ⌙ | ⌙ |
Amend List of Resources for Notification of Data Changes | ✔ | ✔ | ✔ | ⌙ | ✔ | ⌙ | ⌙ | ✔ | ⌙ |
Frequency of Notifications | ✔ | ✔ | ✔ | ✔ | ✔ | ⌙ | ✔ | ✔ | ⌙ |
Filtered Notifications | ✔ | ✔ | ✔ | ✔ | ✔ | ⌙ | ✔ | ✔ | ⌙ |
Time-Bound Subscriptions | ✔ | ✔ | ✔ | ⌙ | ✔ | ⌙ | ✔ | ✔ | ⌙ |
Lost Update Notifications | ✔ | ✔ | ✔ | ⌙ | ✔ | ⌙ | ⌙ | ⌙ | ⌙ |
Capability Discovery | ⌙ | ⌙ | ⌙ | ⌙ | ⌙ | ✔ | ⌙ | ⌙ | ⌙ |
|
Functional Requirements
This section is non-normative.
- F1. Create Events
- A subscribed entity is alerted when a new resource is created.
- F2. Update Events
- A subscribed entity is alerted when an existing resource is updated.
- F3. Delete Events
- A subscribed entity is alerted when an existing resource is deleted.
- F4. Event Filtering
- A subscribed entity can request a subset of all notifications.
- F5. Authorization
- Authorization is enforced on all subscriptions.
- F6. Capability Discovery
- A client is able to discover the notification capabilities of a Solid Storage.
- F7. Handling Subscription Requests
- >When a subscriber makes request for a new subscription, the Solid storage must be able to process the request including the parameters for subscription provided by the client.
- F8. Handling Subscription Modifications
- When a subscriber requests for parameters of a subscription to be modified, the Solid storage must be able to process the request.
Non-Functional Requirements
This section is non-normative.
- NF1. Baz
- Baz
Considerations
This section details privacy, accessibility and ethical considerations.
Privacy Considerations
This section is non-normative.
Accessibility Considerations
This section is non-normative.
Ethical Considerations
This section is non-normative.
References
Informative References
- [ETHICAL-WEB]
- W3C TAG Ethical Web Principles. Daniel Appelquist; Hadley Beeman. W3C. 27 October 2020. TAG Finding. URL: https://www.w3.org/2001/tag/doc/ethical-web-principles/
- [RFC3986]
- Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://datatracker.ietf.org/doc/html/rfc3986
- [RFC6454]
- The Web Origin Concept. A. Barth. IETF. December 2011. Proposed Standard. URL: https://datatracker.ietf.org/doc/html/rfc6454
- [RFC7231]
- Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html
- [SOLID-PROTOCOL]
- Solid Protocol. Sarven Capadisli; Tim Berners-Lee; Ruben Verborgh; Kjetil Kjernsmo; Justin Bingham; Dmitri Zagidulin. W3C Solid Community Group. W3C Editor’s Draft. URL: https://solidproject.org/TR/protocol
- [WEBARCH]
- Architecture of the World Wide Web, Volume One. Ian Jacobs; Norman Walsh. W3C. 15 December 2004. W3C Recommendation. URL: https://www.w3.org/TR/webarch/