feat: adds a name field to the server object

[baywet]

fixes #1821

Tick one of the following options:

• schema changes are included in this pull request
• schema changes are needed for this pull request but not done yet
• no schema changes are needed for this pull request

[ralfhandl]

Could you please add a name to the first Server Object in the test case https://github.com/OAI/OpenAPI-Specification/blob/v3.2-dev/tests/schema/pass/servers.yaml?

(Adding it to the first one should avoid merge conflicts with #4456)

[baywet]

Thanks for the quick review! I have made the requested updates.

[handrews]

@baywet this makes name and description both unrestricted strings. Are there supposed to be limitations on what consistitutes a valid name? The issue mentions using these for code generation.

[baywet]

@handrews I was wondering that myself as I put the pull request together. So I went and looked for precedent work, like the parameter name, the license name, schema properties name, etc...
Although there are implicit limitations (parameters must abide by HTTP query parameters conventions if they are query parameters, path parameter conventions if they are path parameters, json schema properties must be a valid JSON property name, etc...), we don't call any of that explicitly out?

As for code generation, the tool can always run some kind of sanitation routine based on their own domain restrictions.

This is why I decided to leave it open, but happy to narrow it down based on this audience's feedback.

[handrews]

@baywet thanks for the research and summary. If the TSC is fine with continuing in the same vein as existing name fields, I have no objection. We have had some complaints in this area (which I'm too lazy to dig up right now), but choosing the right restrictions is not an obvious thing. On the other hand, we should be a lot more clear in Moonwalk, particularly with full Unicode support being something people now expect.

[lornajane]

I have no objections to either using the field name name, or to leaving the validation pretty open in common with the other fields. If I understood this correctly, the name is for tools outside of OpenAPI to use, we're not suggesting people can use this name to refer to a server entry from anywhere else within the OpenAPI file?

[baywet]

@lornajane correct, name is just informative as far as I understood the initial issue, no reference mechanism from the spec. It may be used in code generation or to produce other generated artifacts (docs, etc...) at which point we should probably leave that up to the tool consuming it.