Jelly protocol profiles

[Ostrzyciel]

Up for discussion: I've recently received some feedback saying that the Jelly spec is rather complex and may be hard to implement and test reliably. Fair enough.

The main reason for the complexity is the wide spectrum of possible applications for Jelly, from IoT to Cloud. Each implementer may choose to implement the spec only partially. But I agree that it's hard to figure out which parts are needed, which are not, and what can interoperate with each other.

I think the solution to this twofold – the first is protocol profiles. The other is compatibility test kits, covered in a follow-up issue (#25).

The spec should have a set of profiles that narrow down the supported capabilities and behaviors. This would probably not be single-dimensional like in OWL. I'm thinking here more of the profiles being like a list of capabilities that your implementation supports or not, closer how Wasm apps list the WASI specs used in the app. For example, support for: physical stream types (one per each – TRIPLES, QUADS, GRAPHS), IRI prefixes, encoding, decoding, RDF-star, etc.

Most of this stuff is already in the stream options header, and the gRPC streaming protocol defines the negotiation behavior for that. We should consider what role should that play here. Should it be moved to the serialization format spec?

There should be clear relations defined between the profiles that allow one to verify if implementation A is compatible with B. I'd assume the answer to be usually "yes", or (maybe) "yes, as long as one of the implementations uses a restricted feature set". This is because the compat burden is mostly on the side of consumers. A producer can support as narrow a slice of the spec as it wishes.

I think it would be nice if we had a profile selector at the start of the spec. Once I select the desired implementation profile, I should be presented with a slimmed-down spec that only includes the parts that I need.