Filters - Custom Filter Dialect/Custom Protocol

We're working on implementing the subscription API, but as we are going trough implementing this on our own as there aren't any language-specific implementations yet, we're a bit hesitant on some things. We're thinking that if language-specific implementations do appear in the future, there might be a problem if someone wants to use their own dialect.

Here's our reasoning: if someone generates their own server based on the OpenAPI specs, it'll generate the models for filters. But if they want to use a custom dialect, like CEL (Common Expression Language) in our case, they'd have to create a custom version of the subscription API specs and potentially provide custom SDKs instead of relying on official SDKs which we can imagine will contain the client or at least client abstraction for communication with subscription API.

We had similar thoughts about sink protocols. There's no way to provide a custom protocol right now. For example, if we wanted to use gRPC (with its own HTTP/2 protocol), we'd have to propose it and wait for it to be added to the official specification.

While we understand that the API specs aim to unify things, we think that implementors/providers should be able to decide on and provide their own filters and protocols.

I think for optional dialects there could be something like:

{ 
  "custom": {
    "type": "sql (Or any other dialect)"
    "expression": "source LIKE '%cloudevents%'"
  }
}

Review the subscription API and sink protocol definitions in the CloudEvents specification, then examine how OpenAPI-generated models represent filters. Compare the proposed custom dialect shape with the current protocol constraints; done means the specification defines how custom filters and protocols are represented and interoperable.