Honza Dvorsky

Found that the k8s API is using this pattern all over the place, and not just for adding descriptions to properties, but also default fields, and I just realized that...

Thinking about this a bit more, maybe we don't need this, here's an alternative idea: as we embrace the design principles of this project outlined in [Project scope and goals](https://swiftpackageindex.com/apple/swift-openapi-generator/0.1.3/documentation/swift-openapi-generator/project-scope-and-goals),...

Blocking on OpenAPI 3.1 support for now, after that's done, we'll be in a better position to decide what to do with this.

Ok, when this PR lands, this will get closed - in OpenAPI 3.1, one can attach `description` (and other core properties, like `deprecated`) directly to a `$ref` schema as well,...

Now that we support OpenAPI 3.1, descriptions on refs are supported. So the solution here is to migrate your document to 3.1, then descriptions will work.

To help inform how this should work (with the considerations of sandboxing, security, usability, and so on), can you provide links to some real-world OpenAPI documents that are split across...

Thank you @andrewse02 for the details, this is great. A few questions that come to mind that we'll need to think about: - what's the namespacing behavior of the generated...

@simonjbeaumont to gather some data.

All of these are feasible, as far as I can tell, so it's really about us choosing how this should work. I'd like to avoid configuration options if at all...

Yeah if constrained to just references to objects as subschemas, those can be handled pretty well, because they have a global name. But all of these aggregate types (except for...