[Registry] I wonder if this example is misleading, as it needs the `usage` to be understood. That might tell me that usage and options should be colocated in an object together one level off of the root?

[duglin]

I wonder if this example is misleading, as it needs the usage to be understood. That might tell me that usage and options should be colocated in an object together one level off of the root?

Is this example of a producer?

Yeah it feels like this would be easier to program to if we had more of this kind of structure:

{
   ...
   "usage": {
      "role": "producer",
      "kafka": {
         "queue": "https://example.com/queue/1234"
      }
   }
}

No, I am not sure about that... I am thinking about two things:

1. How would I model this as a protobuf?
2. How do we avoid the downsides of something like OSBAPI where there are generic overloaded fields that based on some config in the response or context.

_Originally posted by @n3wscott in https://github.com/cloudevents/spec/pull/1041#discussion_r942676618_

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity. Mark as fresh by updating e.g., adding the comment /remove-lifecycle stale.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity. Mark as fresh by updating e.g., adding the comment /remove-lifecycle stale.

[duglin]

Moved to: https://github.com/xregistry/spec/issues/18