Schema property alternative names

[netbeansuser2019]

I would like to suggest to extend schema property by "alternativeName":

"type" : "object",
"properties : {
     "property1" : {
            "type" : "string",
            "alternativeNames" : [
                  "Property1"                   
            ]
     }
}

That to me seems advantage in case of generation clients for 3rd-party-API that it is even not describe by openapi.json especially to reuse "objects type" that just differentiated in case of letters in properties.

[webron]

How would this help client generation though?

[netbeansuser2019]

In context of Java client that call returns JSON you can have just one object field that could eat any variant of property name. That can happens e.g. when service is not developed with taking to acccount openapi specifcation and/or is some development history instead of creation different schema for one group of calls (e.g. old style) and other (new style). ...

As another example see: https://github.com/swagger-api/swagger-codegen/issues/9858

[handrews]

This has been floated at the JSON Schema project as a sort of schema evolution feature. We're unlikely to act on it but it could be done in an extension vocabulary.

[netbeansuser2019]

This has been floated at the JSON Schema project as a sort of schema evolution feature. We're unlikely to act on it but it could be done in an extension vocabulary.

In ideal world yes, but you have to have possibility to describe it even that third-party-no-so-ready or even you have to connect to old thing that it is not even expect to be even touched (rather died after years). Or side of this problem is code convention or even worst limits about variables naming on client side.

BTW: it is really nothing special just analogical to already supported "operationId" in Object Operation if it is reformulate to : "Property1" : { "type" : "string", "operationName" : "property1" } As I have just write it more broader to catch more JSON Object fields under one property in client e.g. in case that old system can provides for one call e.g. "error" for other "Error" or for other "err" and so on so like: if exists JSON error field store it as error field otherwise store look for "Error" ... so in order to choose just one. Frankly speaking I am no such optimist that OpenAPI specification add basic support for expressions so you can even write this like: "Error" : { "type": "String", "operationName": "error1"
}, "error" : { "type": "String", "operationName": "error2"
}, "errorData" : { "type" : "expression", "expression" : { "function" : "concatenate" "parameters": [
{"property": "Error"} {"text": ";"}, {"property": "error"} ] } } So "opererationName" avoid a compilation issues in languages that is variable-names-case-sensitive and "expression" as type can give a possibility to generator of client to generate proper code if such "generator template" gives support for it (as any extension point).

Please could you more explain what you mean by such "extension vocabulary" or even better write down some example.

[bougar]

This would make sense in case I wanted to rename a property name without breaking compatibility with previous versions. The behavior, at least in my use case, would be similar to JsonAlias in Java.

[Loicgeo-pro]

Hi all, I have a need also to digest a JSON having some strange names as input and I don't have the hand to change its specification.

[mehmeteyesin]

@bougar were you able to find a workaround?

[jkoorts]

Here eagerly hoping this feature is now supported

[handrews]

You would need to handle the alternative names at the same level as the regular names, because keywords for a single property cannot be applied to the whole object (which would be needed to find the alternate name). The property1 schema won't even be examined if there isn't a property1, so the proposed approach won't work.

The simplest way to do this is to just ref both property names to the same definition, which can include a canonical name for code generators to use (I'm making up the canonicalName keyword on the spot- as an annotation, it's trivial to implement as an extension vocabulary for OAS 3.1 / JSON Schema 2020-12 because in 2020-12 unknown keywords are automatically treated as annotations):

{
    "$defs": {
        "property1": {
            "type": "string",
            "canonicalName": "property1"
        }
    },
    "type" : "object",
    "properties": {
        "property1": {"$ref": "#/$defs/property1"},
        "Property1": {"$ref": "#/$defs/property1"}
    }
}

[handrews]

OAS 3.1 has full JSON Schema support, and this is really a JSON Schema feature request. Now that the OAS doesn't define a custom JSON Schema variant, this is out of scope for us.