String parameter get a OpenApiDateTime type

[talamram]

Hi,

I tried to parse a document with a parameter with this properties:

in: "query",
name: "version",
required: true,
default: "2018-07-13",
pattern: "^\d{4}-\d{2}-\d{2}$",
type: "string",
description: "Release date of the API version"

This parameter got the type OpenApiDateTime although it should be a string.

Thanks

[darrelmiller]

This will need some investigation. I believe we attempt to infer the type from trying to parse the data. Using the type to enforce the type is problematic for folks who want to have dateTime values because JSON has no notion of DateTime. We would need to look into using the format property to provide the type hint instead of inferring the type.

[PerthCharern]

@darrelmiller Agree that trying to parse the data is not the correct way to do it. We should stick with the explicit types recognized by OAS https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#data-types

I'll take a look at this specific issue.

[PerthCharern]

I'll modify the way CreateAny works to take in some hint about the type and format based on the table above.

[PerthCharern]

Apologies for the delay. Having looked into this a bit more, I am not quite sure if the route I mentioned above is the way to go.

We can rely on the type and the format given to parse a simple value parameter, though that might be a bit problematic, since people do not always fully specify the format. In that case, a lot of parameters will simply be parsed into OpenApiString, which might not be the best type to describe the data.

Furthermore, there's no way to get hints about the inner values of an object. If the default/example is given at the object level, we still need to rely on parsing the data to get the most appropriate OpenApiAny to use.

@talamram In your particular example, even though you did not specify the format explicitly, the default value represents a date, so our system parses it to OpenApiDateTime. In some way, this is the most specific, hence most appropriate data type that we can get based on the default string you have supplied, though it doesn't match the type and format given.

Could you elaborate on the issue this is causing? I would like to understand how you are using these OpenApiAny types downstream.

[darrelmiller]

I wonder if we can take the approach where if type and format is not provided then we can try and infer the data type but if it is then we respect the provided data.

[PerthCharern]

Thanks Darrel. I think that makes sense. To summarize, I'll go with the following route:

• Type provided. Use that type.
  • If data conflicts with the type, leave the field empty. (Will think about this case a bit more)
• Type not provided. Infer from the data.