From 287af06aec452badb8b582806532267fc3d17ae3 Mon Sep 17 00:00:00 2001 From: Rahul Gupta Date: Fri, 11 Apr 2025 23:02:20 +0530 Subject: [PATCH] Add HTTP Query Notifications Adds HTTP Query Notifications Protocol extends the Solid Notifications Protocol for streaming HTTP notifications using the QUERY method: + to allow subscriptions to be established from any Solid resource, and + to combine the subscription for and the receipt of notifications into a single HTTP request/response round-trip. --- shq-notifications-flow-discovery.mmd | 7 + shq-notifications-flow-sunscription.mmd | 7 + shq-protocol.html | 1014 +++++++++++++++++++++++ 3 files changed, 1028 insertions(+) create mode 100644 shq-notifications-flow-discovery.mmd create mode 100644 shq-notifications-flow-sunscription.mmd create mode 100644 shq-protocol.html diff --git a/shq-notifications-flow-discovery.mmd b/shq-notifications-flow-discovery.mmd new file mode 100644 index 0000000..8b3a581 --- /dev/null +++ b/shq-notifications-flow-discovery.mmd @@ -0,0 +1,7 @@ +sequenceDiagram + + participant Client + participant Server + + Client ->> Server: HEAD Topic Resource + Server ->> Client: HTTP Accept-Query: "application/ld+json"#59;
profile="http://www.w3.org/ns/json-ld#35;context
https://www.w3.org/ns/solid/notifications-context/v1" diff --git a/shq-notifications-flow-sunscription.mmd b/shq-notifications-flow-sunscription.mmd new file mode 100644 index 0000000..3e9639a --- /dev/null +++ b/shq-notifications-flow-sunscription.mmd @@ -0,0 +1,7 @@ +sequenceDiagram + participant Client + participant Server + + Client ->> Server: Subscription Request + Server ->> Client: Notification Channel + Server -->> Client: Notification Messages diff --git a/shq-protocol.html b/shq-protocol.html new file mode 100644 index 0000000..988514a --- /dev/null +++ b/shq-protocol.html @@ -0,0 +1,1014 @@ + + + + + Solid HTTP Query Notifications Protocol + + + + + + + + + +
+
+
+

Solid HTTP Query Notifications Protocol

+ +

Unofficial Draft,

+ +
+ More details about this document + +
+
This version
+
https://solid.github.io/notifications/shq-protocol
+
+ + + +
+
History
+
Commit history
+
+ +
+
Editors
+
Rahul Gupta
+
+ +
+
Authors
+
Rahul Gupta
+
+ +
+
Created
+
+
+ +
+
Published
+
+
+ +
+
Modified
+
+
+ +
+
Feedback
+
GitHub solid/notifications (pull requests, new issue, open issues)
+
+ +
+
Language
+
English
+
+ +
+
Document Type
+
Specification
+
+ +
+
Version
+
0.1.0
+
+ +
+
In Reply To
+
About Solid
+
Notifications Panel Charter
+
+ +
+
Policy
+
+
+
Rule
+
Offer
+
Unique Identifier
+
https://solid.github.io/notifications/http-query#document-policy-offer
+
Target
+
https://solid.github.io/notifications/shq-protocol
+
Permission
+
+
+
Assigner
+
W3C Solid Community Group
+
Action
+
+ +
+
+
+
+
+
+
+ +

Copyright © 2025 the Contributors to Solid HTTP Query Notifications Protocol, Unofficial Draft. All code snippets are in the public domain, CC0.

+ +
+
+ +
+
+

Abstract

+
+

This specification extends the Solid Notification Protocol to provide a faster mechanism for receiving streaming HTTP notifications from Solid resources.

+
+
+ +
+

Status of This Document

+
+

This report was not published by the Solid Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.

+ +

Publication as an Unofficial Draft implies that it is not endorsed by anyone. This 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. You are invited to contribute any feedback, comments, or questions you might have.

+
+
+ + + +
+

Introduction

+
+

This section is non-normative.

+ +

The Solid Notifications Protocol [SOLID-NOTIFICATIONS-PROTOCOL] defines an extensible, HTTP-based framework by which client applications can receive notifications for HTTP resource changes.

+ +

The Solid HTTP Query (SHQ) Notifications Protocol specifies a faster mechanism for receiving streaming HTTP [SOLID-STREAMINGHTTPCHANNEL2023] notifications that conform to the Solid Notifications Protocol by combining the subscription for and the receipt of notifications into a single HTTP request/response round-trip.

+ +

This specification is for:

+ +
    +
  • Server developers that want to enable clients to listen for updates to particular resources.
    • +
  • Application developers who want to implement a client to listen for updates to particular resources.
    • +
+ +

In addition to this specification, readers might find the Use Cases and Requirements for Notifications Protocol [NOTIFICATIONS-UCR] document useful.

+ +
+

Overview

+
+

This section is non-normative.

+ +

The Solid HTTP Query Notification protocol allows client applications to discover notification services available for any given resource.

+ +

The following diagram shows the high-level interactions involved in the discovery of HTTP Query Notifications.

+ +
+
Solid HTTP Query Notifications Discovery
+ + +
+ +

Client applications can use the usual discovery flow [SOLID-NOTIFICATIONS-PROTOCOL] to learn more about the available subscription mechanism.

+ +

Clients make a QUERY [HTTP-QUERY] request to the resource to start receiving notifications.

+ +

The following diagram shows the high-level interactions involved in subscribing for and receiving streaming HTTP [SOLID-STREAMINGHTTPCHANNEL2023] notifications:

+ +
+
Solid HTTP Query Notifications Subscription
+ + +
+
+
+ +
+

Namespaces

+
+ + + + + + + + + + + + + + + + +
Prefixes and Namespaces
PrefixNamespaceDescription
notifyhttp://www.w3.org/ns/solid/notifications#Solid Notifications
+
+
+ +
+

Conformance

+
+

This section describes the conformance model of the Solid HTTP Query Notifications Protocol.

+ +
+

Normative and Informative Content

+
+

All assertions, diagrams, examples, and notes are non-normative, as are all sections explicitly marked non-normative. Everything else is normative.

+ +

The key words “MUST”, “MUST NOT”, “SHOULD”, and “MAY” are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

+ +

The key words “strongly encouraged”, “strongly discouraged”, “encouraged", “discouraged", “can", “cannot”, “could”, “could not”, “might”, and “might not” are used for non-normative content.

+
+
+ +
+

Specification Category

+
+

The Solid HTTP Query Notifications Protocol identifies the following Specification Category to distinguish the types of conformance: API, notation/syntax, set of events, protocol.

+
+
+ +
+

Classes of Products

+
+

The Solid HTTP Query Notifications Protocol identifies the following Classes of Products for conforming implementations. These products are referenced throughout this specification.

+ +
+
Server
+
A Server builds on an HTTP server [RFC9110] and [RFC9112] by defining media types, HTTP header fields, and the behaviour of resources, as identified by link relations. The Server combines the roles of Resource Server, Subscription Server and Notification Sender defined in the Solid Notifications Protocol [SOLID-NOTIFICATIONS-PROTOCOL].
+
Client
+
A Client that builds on HTTP client [RFC9110], [RFC9112], and [FETCH] by defining behaviour in terms of fetching across the platform. The Client combines the roles of Discovery Client, Subscription Client and Notification Receiver defined in the Solid Notifications Protocol [SOLID-NOTIFICATIONS-PROTOCOL].
+
+
+
+ +
+

Interoperability

+
+

Interoperability occurs between Client–Server.

+ +
+
Client–Server interoperability
+
Interoperability of implementations for Client and Servers is tested by evaluating an implementation’s ability to request and respond to HTTP messages that conform to the Solid HTTP Query Notifications Protocol.
+
+
+
+
+
+
+
+ +
+

Protocol

+
+

The Solid Notifications Protocol [SOLID-NOTIFICATIONS-PROTOCOL] specifies a Linked Data-based protocol for sending notifications to client applications upon updates to resources in the Solid ecosystem while respecting resource-based access controls and privacy.

+ +

Solid HTTP Query (SHQ) Notifications Protocol extends the Solid Notifications Protocol specifically for streaming HTTP [SOLID-STREAMINGHTTPCHANNEL2023] notifications using the QUERY [HTTP-QUERY] method:

+ +
    +
  • to allow subscriptions to be established from any Solid resource, and
    • +
  • to combine the subscription for and the receipt of notifications into a single HTTP request/response round-trip.
    • +
+ +

This specification uses JSON-LD [JSON-LD11] as the preferred data format, and https://www.w3.org/ns/solid/notifications-context/v1 as a URI for the JSON-LD context and as a value of the profile parameter used for content negotiation.

+ +

This specification does not require a specific authentication and authorization mechanism to be used. Implementations are encouraged to use existing approaches, such as those described in the Solid Protocol sections on Authentication and Authorization [SOLID-PROTOCOL].

+ +
+

Discovery

+
+ + A Server advertises the capability of a resource to provide SHQ notification using the Accept-Query header field. Further, the Client can discover further information about SHQ notifications available on the resource by accessing the description resource [SOLID-NOTIFICATIONS-PROTOCOL].

+ +

When a resource supports SHQ notifications:

+ +
    + +
  • A Server MUST set the Accept-Query header field to "application/ld+json"; profile="http://www.w3.org/ns/json-ld#context https://www.w3.org/ns/solid/notifications-context/v1" on any resource that supports notifications.
    • + +
  • A Server MUST advertise the capability to subscribe to notifications using the QUERY [HTTP-QUERY] method on the corresponding description resource.
    • + +
  • A Server MUST use the Description Resource Data Model in the corresponding description resource response content.
    • +
+
+
+ +
+

Subscription

+
+ +

A Client subscribes to SHQ notifications by making a QUERY request to a resource. + The content of the subscription request describes the desired streaming HTTP [SOLID-STREAMINGHTTPCHANNEL2023] notification channel [SOLID-NOTIFICATIONS-PROTOCOL].

+ +

To subscribe to SHQ notifications from a resource:

+ + +

When a resource supports SHQ notifications:

+ +
    +
  • A Server MUST allow the OPTIONS [RFC9110] and QUERY [HTTP-QUERY] methods on the resource.
    • + + + +
  • A Server MUST accept QUERY requests targeting the resource with the Content-Type header field set to application/ld+json [JSON-LD11].
    • + + +
+ +
+
Example: Subscription request.
+ 
+QUERY /guinan/profile HTTP/1.1
+Host: example.org
+Accept: application/ld+json
+Content-Type: application/ld+json
+
+{
+  "@context": [
+    "https://www.w3.org/ns/solid/notifications-context/v1"
+  ],
+  "topic": [
+    "https://example.org/guinan/profile",
+  ],
+}
+ + +

When the subscription request is not successful:

+ +
    +
  • A Server MUST respond with a 415 status code for QUERY requests with unsupported values in the profile parameter for the application/ld+json media type.
    • + +
  • A Server MUST respond with a 422 status code [RFC4918] if it is unable to process the contained instructions, including unrecognised JSON-LD context in representation data.
    • +
+ +

When the subscription request returns notifications, the first part of the response provides information describing the notification channel [SOLID-NOTIFICATIONS-PROTOCOL]. Before serving notification messages:

+ + + +
+
+ +
+

Notifications

+
+

Unlike the Solid Notifications Protocol [SOLID-NOTIFICATIONS-PROTOCOL], the response to a subscription request also serves notifications. That is to say, the subscription service doubles up as the notification channel.

+ +

Otherwise, the notification channel is identical to the Solid StreamingHTTPChannel2023 [SOLID-STREAMINGHTTPCHANNEL2023].

+ +
+
Example: Notification Response.
+ 
+HTTP/1.1 200 OK
+Accept-Query: "application/ld+json";
+  profile="http://www.w3.org/ns/json-ld#context https://www.w3.org/ns/solid/notifications-context/v1"
+Location: https://example.org/guinan/
+Content-Type: text/turtle
+
+@prefix as: <https://www.w3.org/ns/activitystreams#> .
+@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
+@prefix notify: <http://www.w3.org/ns/solid/notifications#> .
+@prefix xs: <ttp://www.w3.org/2001/XMLSchema#> .
+
+<https://example.org/guinan/profile?notify=ac748712> notify:topic <https://example.org/guinan/profile/> ;
+	notify:startAt "2023-01-01T07:00:00.000Z"^^xs:dateTime ;
+	notify:endAt "2023-01-01T09:00:00.000Z"^^xs:dateTime ;
+	notify:rate "PT5M"^^xs:duration ;
+	notify:state "e75-TFJH" .
+
+<urn:uuid:fc8b5af4-bd7e-4fd1-a649-afcbd0e1c083> as:object <https://example.org/guinan/profile/> ;
+	notify:state "128f-MtYev" ;
+	as:published "2021-08-05T01:01:49.550Z"^^xs:dateTime ;
+	a as:Update .
+
+<urn:uuid:a4da6738-6be0-11ed-90bd-1be4ba6b6b33> as:object <https://example.org/guinan/profile/image> ;
+	as:target <https://example.org/guinan/profile/> ;
+	as:published "2022-11-24T11:55:31.483Z"^^xs:dateTime ;
+	a as:Add .
+ +

To modify the response, a Client initiates a new subscription request with the id of the existing notification channel and any modifications to it. If the request is successful, the Client will receive notifications in the response to the modifying subscription request. In such a case:

+ +
    +
  • A Server MUST close the original response.
    • +
  • A Server MUST reuse the id from the description of the existing notification channel.
    • +
+ +
+
+ +
+

Notification Message

+
+

Notification Messages are identical to the Solid Notifications Protocol § 2.4 [SOLID-NOTIFICATIONS-PROTOCOL]. Notification Messages are sent in the response after the description of the notification channel.

+
+
+
+
+ +
+

Data Model

+
+

This section specifies any modifications to data models used in Solid Notifications Protocol § 3 [SOLID-NOTIFICATIONS-PROTOCOL].

+ +
+

Description Resource

+
+

The description resource [SOLID-NOTIFICATIONS-PROTOCOL] should additionally specify the following properties:

+ + + +
+
Example: Representation of a description resource.
+ + 
{
+  "@context": [
+    "https://www.w3.org/ns/solid/notifications-context/v1"
+  ],
+  "id": "https://example.org/guinan/profile",
+  "http-query-subscription": {
+    "id": "https://example.org/guinan/",
+    "feature": ["endAt", "rate", "state"]
+  },
+  "subscription": [{
+    "id": "https://websocket.example/subscription",
+    "channelType": "WebSocketChannel2023",
+    "feature": ["endAt", "rate", "state"]
+  }],
+  "channel": [{
+    "id": "https://channel.example/guinan/profile",
+    "type": "WebSocketChannel2023",
+    "topic": "https://example.org/guinan/profile",
+    "receiveFrom": "wss://websocket.example/guinan/profile",
+    "rate": "PT1M"
+  }]
+}
+
+
+
+ +
+

Subscription Service

+
+

The Subscription Service Data Model is identical to the Solid Notifications Protocol § 3.2 [SOLID-NOTIFICATIONS-PROTOCOL] except:

+ +
    +
  • The channelType property MUST be omitted.
    • +
+ +
+
Example: Representation of a subscription service.
+ + 
{
+  "@context": [
+    "https://www.w3.org/ns/solid/notifications-context/v1"
+  ],
+  "id": "https://example.org/guinan/profile",
+  "feature": ["endAt", "rate", "state"]
+}
+
+
+
+ +
+

Notification Channel

+
+

The Notification Channel Data Model is identical to the Solid Notifications Protocol § 3.3 [SOLID-NOTIFICATIONS-PROTOCOL] for the Solid StreamingHTTPChannel2023 [SOLID-STREAMINGHTTPCHANNEL2023], except:

+ +
    +
  • The channelType property MUST be omitted.
    • +
  • The receiveFrom property MUST be omitted.
    • +
+ +
+
+ +
+

Notification Message

+
+

The Notification Message Data Model is identical to the Solid Notifications Protocol § 3.4 [SOLID-NOTIFICATIONS-PROTOCOL].

+
+
+
+
+ +
+

Considerations

+
+

This section details security and privacy considerations.

+ +

Some of the normative references with this specification point to documents with a Living Standard or Draft status, meaning their contents can still change over time. It is advised to monitor these documents, as such changes might have implications.

+ +
+

Security Considerations

+
+

This section is non-normative.

+ +

Servers are strongly discouraged from exposing information beyond the minimum amount necessary to enable a feature. Clients are strongly discouraged from exposing information beyond the minimum amount necessary to subscribe to updates about particular resources.

+ +

Clients are discouraged from sending subscription requests to untrusted subscription services, including localhost or any other loopback IP address, in order to avoid making arbitrary requests.

+
+
+ +
+

Privacy Considerations

+
+

This section is non-normative.

+
+
+ +
+

Security and Privacy Review

+
+

This section is non-normative.

+ +

These questions provide an overview of security and privacy considerations for this specification as guided by [SECURITY-PRIVACY-QUESTIONNAIRE].

+ +
+
What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?
+
There are no known security impacts of the features in this specification.
+ +
Do features in your specification expose the minimum amount of information necessary to enable their intended uses?
+
Yes.
+ +
How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?
+
Access to resources is only granted to authorized access subjects. The request and response content can contain any data (including that which identifies or refers to agents that control the Client and Server.) Meaningful consent to any personal data that Clients include about agents associated with themselves or topic resources [SOLID-NOTIFICATIONS-PROTOCOL] of interest are extended to the Client. Clients and Servers are discouraged from exposing information beyond the amount necessary to enable or use a feature.
+ +
How do the features in your specification deal with sensitive information?
+
The features do not require sensitive information to obtained or exposed.
+ +
Do the features in your specification introduce new state for an origin that persists across browsing sessions?
+
No.
+ +
Do the features in your specification expose information about the underlying platform to origins?
+
No.
+ +
Does this specification allow an origin to send data to the underlying platform?
+
No. Servers might be able to redirect to other resources, (e.g., the https: URLs to file:, data:, or blob: URLs), but no such behaviour is defined by this specification.
+ +
Do features in this specification allow an origin access to sensors on a user’s device
+
No.
+ +
What data do the features in this specification expose to an origin? Please also document what data is identical to data exposed by other features, in the same or different contexts.
+
No detail about another origin’s state is exposed. When servers participate in the CORS protocol [FETCH], HTTP requests from different origins [RFC6454] may be allowed. This feature does not add any new attack surface above and beyond normal CORS requests, so no extra mitigation is deemed necessary.
+ +
Do features in this specification enable new script execution/loading mechanisms?
+
No.
+ +
Do features in this specification allow an origin to access other devices?
+
No.
+ +
Do features in this specification allow an origin some measure of control over a user agent’s native UI?
+
No.
+ +
What temporary identifiers do the features in this specification create or expose to the web?
+
The subscription response content can contain an identifier for the notification channel which is only exposed to authorized Clients.
+ +
How does this specification distinguish between behaviour in first-party and third-party contexts?
+
Not Applicable.
+ +
How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
+
No different than in the browser’s 'normal' state.
+ +
Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
+
Yes, in Security Considerations and Privacy Considerations.
+ +
Do features in your specification enable origins to downgrade default security protections?
+
No.
+ +
How does your feature handle non-"fully active" documents?
+
Not Applicable.
+
+
+
+
+
+ +
+

Changelog

+
+

This section is non-normative.

+
+
+ +
+

Acknowledgements

+
+

The Community Group gratefully acknowledges the work that led to the creation of this specification, and extends sincere appreciation to those individuals that worked on technologies and specifications that deeply influenced our work.

+ +

The Community Group would like to thank the following individuals for their useful comments, both large and small, that have led to changes to this specification over the years:

+ +
    +
  • Aaron Coburn
    • +
  • Ángel Araya
    • +
  • Christoph Braun
    • +
  • Dmitri Zagidulin
    • +
  • elf Palvlik
    • +
  • Graham Klyne
    • +
  • Hadrian Zbarcea
    • +
  • Henry Story
    • +
  • Jackson Morgan
    • +
  • Jamie Fiedler
    • +
  • Jarlath Holleran
    • +
  • Joachim Van Herwegen
    • +
  • Justin Bingham
    • +
  • Kevin Howard
    • +
  • Kjetil Kjernsmo
    • +
  • Michiel de Jong
    • +
  • Pete Edwards
    • +
  • Rahul Gupta
    • +
  • Ruben Verborgh
    • +
  • Sarven Capadisli
    • +
  • Ted Thibodeau Jr
    • +
  • Tim Berners-Lee
    • +
  • Wout Slabbinck
    • +
  • Wouter Termont
    • +
  • దామోదర
    • +
+
+
+ +
+

References

+
+
+

Normative References

+
+
+
[ACTIVITYSTREAMS-VOCABULARY]
+
Activity Streams. James Snell; Evan Prodromou. W3C. 23 May 2017. W3C Recommendation. URL: https://www.w3.org/TR/activitystreams-vocabulary/
+
[JSON-LD11]
+
JSON-LD 1.1. Gregg Kellogg; Pierre-Antoine Champin; Dave Longley. W3C. 16 July 2020. W3C Recommendation. URL: https://www.w3.org/TR/json-ld11/
+
[POWDER-DR]
+
Protocol for Web Description Resources (POWDER): Description Resources. Phil Archer; Kevin Smith; Andrea Perego. W3C. 1 September 2009. W3C Recommendation. URL: https://www.w3.org/TR/powder-dr/
+
[HTTP-QUERY]
+
The HTTP QUERY Method. J. Reschke; J.M. Snell; M. Bishop. 4 April 2025. Internet Draft, HTTPWG. URL: https://httpwg.org/http-extensions/draft-ietf-httpbis-safe-method-w-body.html
+
[RDF11-CONCEPTS]
+
RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/
+
[RFC2119]
+
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
+
[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
+
[RFC4918]
+
HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV). L. Dusseault, Ed. IETF. June 2007. Proposed Standard. URL: https://datatracker.ietf.org/doc/html/rfc4918
+
[RFC8174]
+
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc8174
+
[RFC8288]
+
Web Linking. M. Nottingham. IETF. October 2017. Proposed Standard. URL: https://httpwg.org/specs/rfc8288.html
+
[RFC9110]
+
HTTP Semantics. R. Fielding, M. Nottingham, J. Reschke, Eds. IETF. June 2022. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc9110
+
[RFC9112]
+
HTTP/1.1. R. Fielding, M. Nottingham, J. Reschke, Eds. IETF. June 2022. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc9112
+
[SOLID-NOTIFICATIONS-PROTOCOL]
+
Solid Notifications Protocol. Sarven Capadisli et. al. W3C Solid Community Group. Draft Community Group Report, Version 0.4.0. URL: https://solidproject.org/TR/notifications-protocol
+
[SOLID-PROTOCOL]
+
Solid Protocol. Sarven Capadisli; Tim Berners-Lee; Kjetil Kjernsmo. W3C Solid Community Group. Draft Community Group Report, Version 0.11.0. URL: https://solidproject.org/TR/protocol
+
[SOLID-STREAMINGHTTPCHANNEL2023]
+
Solid StreamingHTTPChannel2023. elf Pavlik. W3C Solid Community Group. Draft Community Group Report, Version 0.1.0. URL: https://solidproject.org/TR/streaming-http-channel-2023
+
[XMLSCHEMA11-2]
+
W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. David Peterson; Sandy Gao; Ashok Malhotra; Michael Sperberg-McQueen; Henry Thompson; Paul V. Biron et al. W3C. 5 April 2012. W3C Recommendation. URL: https://www.w3.org/TR/xmlschema11-2/
+
+
+
+ +
+

Informative References

+
+
+
[SOLID-TECHNICAL-REPORTS]
+
Solid Technical Reports. Sarven Capadisli. W3C Solid Community Group. 03 June 2024. Living Document. URL: https://solidproject.org/TR/
+
[NOTIFICATIONS-UCR]
+
Solid Notifications Use Cases and Requirements. Sarven Capadisli. W3C Solid Community Group. 28 November 2022. W3C Editor’s Draft. URL: https://solid.github.io/notifications-panel/notifications-ucr
+
[SECURITY-PRIVACY-QUESTIONNAIRE]
+
Self-Review Questionnaire: Security and Privacy. Theresa O'Connor; Peter Snyder. W3C. 16 December 2021. W3C Group Note. URL: https://www.w3.org/TR/security-privacy-questionnaire/
+
[W3C-PROCESS]
+
W3C Process Document. Elika J. Etemad / fantasai; Florian Rivoal. W3C Process Community Group. 12 June 2023. URL: https://www.w3.org/policies/process/
+
+
+
+
+
+
+
+
+ + + + + +