Gracefully handle or ignore properties that do not have a type

[alexklibisz]

Hi, is there a way to gracefully handle or ignore properties that do not have a type?

For example, some properties in the Google Maps openapi specification are missing a type. If you download the release I linked, you'll see an example on line 23140, where a property only has a description:

properties:
  steps:  
    description: Contains detailed directions for walking or driving steps in transit directions. Substeps are only available when travel_mode is set to "transit". The inner steps array is of the same type as steps.

Despite it being pretty useless, it seems like this is might actually be a valid property, as per: https://swagger.io/docs/specification/data-models/data-types/#any

[blast-hardcheese]

Oh dear.

I guess the only sensible thing would be to fall back to String since that's the wire encoding? Json would be too much structure.

What's the Google Maps API say about what valid values are, or is this like metadata associated with a pin that's intended to be retrieved later by consuming applications?

[alexklibisz]

Oh dear.

I agree :)

I opened a ticket here: googlemaps/openapi-specification#361

Why do you say Json would be too much structure?

[blast-hardcheese]

@alexklibisz For an arbitrary parameter, it would require double-quoting.

Consider a query-string %foo=bar, attempting to decode this as JSON would end up failing due to missing url-encoded quotes. We can add those quotes in during deserialization, but then at encoding we'd have to strip them back out again otherwise we're not round-tripping faithfully.

If we leave this as String, that could be up to the user to choose what to do in that situation, without worrying about opening an issue to guardrail and waiting for a patch release 🙂

I am open to other suggestions here, however adding some form of Any stretches the definition of "principled" in guardrail's project statement.

Eager to see what googlemaps' response is though!