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

[csarven]

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 #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:

• #server-notification-channel-resource-jsonld-context
• #server-subscription-request-response
• #subscription-request-context

Adds:

• #json-ld-context

---

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.

[acoburn]

I agree that achieving consistency here is important, but this change goes in the opposite direction of achieving interoperability.

If we intend to support JSON-LD, it is important to align on a particular @context IRI. The reason here is that it cannot be assumed that production systems will dereference arbitrary context values (this is a major security risk). If we require a particular context value, it allows us to both support JSON-LD and also the corresponding interoperability.

I would go in a slightly different direction with this PR; instead, I would propose using specific profile values in the references to Accept headers. IOW, I would suggest that we use:

Accept: application/ld+json; profile="https://www.w3.org/ns/solid/notification/v1"

This will allow clients to indicate to servers that they support this particular flavor of constrained JSON-LD (as opposed to any JSON-LD serialization)

[csarven]

This PR is intended to clarify that:

• the required format is JSON-LD;
• http://www.w3.org/ns/solid/notifications as the vocabulary, and;
• the JSON-LD context is https://www.w3.org/ns/solid/notification/v1.

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]

Updated in b73a814 . 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.

[RubenVerborgh]

I can ok this, but I think we're now ad-hoc tackling some of #105; I'd like to see those then documented elsewhere too (future issue/PR is fine).