OpenAPI.NET icon indicating copy to clipboard operation
OpenAPI.NET copied to clipboard

Example parsed as PrimitiveType.DateTime is problematic

Open Blackbaud-ChristiSchneider opened this issue 4 years ago • 2 comments

I have OpenApi documents that I'm parsing with this library. I have several examples where I am unable to get information I need from them. There are two issues I'm running into.

I'm not sure why date is being included as a primitive type anyway because the MSDN article on primitive types does not include date.

1. Cannot check if offset was included

I have an example value: "start_date": "2017-12-01T00:00:00"

When the document is parsed, this example value is an OpenApiDateTime which has a value type of DateTimeOffset. I would like to be able to validate that an offset is included in the original example.

Because the type is DateTimeOffset and there doesn't seem to be a way to get the original string value from the parsed example, I cannot do this check.

2. Non-dates are parsed as dates

I have an example value: "account_number": "01-5410-00"

When the document is parsed, this example value is an OpenApiDateTime even though it is decidedly not a date and isn't even a format I would recognize as a date.

Another example is this header, where the version number is a date string:

{
  "name": "x-ms-version",
  "value": "2015-12-11"
}

Another example is a time value: "start_time": "07:00"

It was a design error to try and interpret the data types of example values. We should never have tried to do it because it causes way too many problems. I think we need to make a breaking change to the library to just treat all example values as simply their native JSON compatible values. Additional validators can be created and run as a secondary process to verify the validity of examples.

darrelmiller avatar Dec 13 '20 19:12 darrelmiller

I think that would fix issues like #420 as well. It's probably helpful to check array vs object vs primitive still but I would welcome a breaking change to fix this. My workaround code is not pretty.