search

solid / notifications

Solid Notifications Technical Reports
https://solid.github.io/notifications/protocol
MIT License
11 stars 7 forks source link

Remove specific constraint of JSON-LD compacted-document-form #122

Closed csarven closed 1 year ago

csarven commented 1 year ago

The primary purpose of this PR is to set a uniform data format in the Solid Notifications Protocol based on the data in current requirements (table below). The PR resolves https://github.com/solid/notifications/issues/105 .

Requirement media-type Constraints
#server-notification-channel-resource-accept application/ld+json -
#server-notification-channel-resource-jsonld-context application/ld+json Specific serialization of dfn-compacted-document-form
#server-subscription-request-accept application/ld+json -
#server-subscription-request-content-type application/ld+json -
#server-subscription-request-response application/ld+json Specific serialization of dfn-compacted-document-form
#notification-data-model application/ld+json dfn-compacted-document-form

The data shows that while servers (resource server and notification server) are capable of accepting any JSON-LD serialization, the servers are required to materialise a JSON-LD compacted document form or a specific serialization of JSON-LD compacted document form. Clients are expected to produce and consume any JSON-LD serialization.

The rationale of this PR is to simplify the requirements without code breaking changes or introducing specific code that may not be part of off the shelf JSON-LD libraries. It achieves that by removing the additional constraint that is a specific serialization of the JSON-LD compacted document form.

The PR removes:

Adds:

As noted elsewhere, there are legitimate reasons to use a "light" data format, e.g., by requiring only JSON-LD compacted document form, a specific serialization of JSON-LD compacted document form, or maybe even something else entirely. That can be pursued by revisiting the requirements as a whole for both servers and clients in addition to advisements.

I suggest that the next change should at least consider setting JSON-LD compacted document form as the required format for both clients and servers.

csarven commented 1 year ago

This PR is intended to clarify that:

I don't see how this goes in the opposite direction of interoperability. (Is the Solid Protocol non-interoperable because it doesn't set a specific JSON-LD serialization?).

If there is language that can help to improve what's intended, surely we can adjust? What's the specific text that's an issue?

Implementations are not required to dereference arbitrary contexts. They can reject when they encounter anything they don't (want to) understand or deem to be untrusted.

I've no objection to using application/ld+json; profile="https://www.w3.org/ns/solid/notification/v1", though I'll emphasise that is not the minimal change that this PR was going for, i.e., resolve the current discrepancies for the next release of the spec.

Are people implementing or commit to implementing with profile?

csarven commented 1 year ago

Updated in https://github.com/solid/notifications/pull/122/commits/b73a814d5baf9dd22cb54adbf5b546afad7c1bf2 . Hopefully that brings us closer to what's intended. Will get back to re-structuring the content and markup after this PR - partly due to resolving other PRs.