Conversation
elf-pavlik
left a comment
elf-pavlik
left a comment
There was a problem hiding this comment.
This PR proposes
- Client
- Notification Server
- Resource Server
I think we should look into something a little bit more specific, for the Subscription flow:
- Subscription Client
- Subscription Server
- Resource Server
For the Notification flow:
- Notifications Sender
- Notifications Receiver
This should avoid confusing naming since for target (delivery) based notifications flows, currently Webhook and LDN
- Notifications Sender - acts as HTTP client
- Notifications Receiver - acts as HTTP server
|
|
||
| <dl> | ||
| <dt about="#Client" property="skos:prefLabel" rel="skos:relatedMatch" resource="spec:Consumer" typeof="skos:Concept"><dfn id="Client">Client</dfn></dt> | ||
| <dd about="#Client" property="skos:definition">A <em>client</em> that builds on HTTP <cite>client</cite> [<cite><a class="bibref" href="#bib-rfc7230">RFC7230</a></cite>], [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>], and [<cite><a class="bibref" href="#bib-fetch">FETCH</a></cite>] by defining behaviour in terms of fetching across the platform.</dd> |
There was a problem hiding this comment.
I suggest Subscription Client, since in notifications flow the Notifications Receiver can act as a client or as a server, depending on the type of created subscription.
| <dt about="#Client" property="skos:prefLabel" rel="skos:relatedMatch" resource="spec:Consumer" typeof="skos:Concept"><dfn id="Client">Client</dfn></dt> | ||
| <dd about="#Client" property="skos:definition">A <em>client</em> that builds on HTTP <cite>client</cite> [<cite><a class="bibref" href="#bib-rfc7230">RFC7230</a></cite>], [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>], and [<cite><a class="bibref" href="#bib-fetch">FETCH</a></cite>] by defining behaviour in terms of fetching across the platform.</dd> | ||
| <dt about="#NotificationServer" property="skos:prefLabel" rel="skos:relatedMatch" resource="spec:RespondingAgent" typeof="skos:Concept"><dfn id="NotificationServer">Notification Server</dfn></dt> | ||
| <dd about="#NotificationServer" property="skos:definition">A <em>notification server</em> that builds on HTTP <cite>server</cite> [<cite><a class="bibref" href="#bib-rfc7230">RFC7230</a></cite>] and [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>].</dd> |
There was a problem hiding this comment.
I suggest Subscription Server, since in notifications flow the Notifications Sender can act as a server or as a client depending on the type of created subscription.
|
Terminology wasn't modified in this PR so github doesn't allow inline suggestions on those lines. I made dedicated PR with matching updates for two term definitions to use subscription client #128 |
|
Merging as per CG agreement: https://github.com/solid/notifications-panel/blob/main/meetings/2022-12-01.md#update-conformance-model with the understanding that the requested changes are accepted - a separate PR will be created to add definitions for subscription client and server and notification sender and receiver ( #129 ). Will also merge #128 and #132 as part of the follow ups. |
3 participants
This PR develops the under-specified
#conformancemodel. Resolves #106 .The work herein follows the guidelines in https://www.w3.org/TR/spec-variability/ and https://www.w3.org/TR/qaframe-spec/ , and applies http://www.w3.org/ns/spec# .
To simplify the review process, this PR focuses on the
#conformancesection and leaves out updates intended to be throughout the specification corresponding to these changes that will be included in a follow up PR.