Breaking change false positive when adding "type: object" to schema with "properties"

[mikekistler]

openapi-diff currently reports a breaking change when a schema that previously had no "type" field but did have "properties" adds "type: object" in the new API definition.

The new version has a different type 'object' than the previous one ''.

ref: Azure/azure-rest-api-specs#14830

A schema that contains "properties" should be considered to be implicitly "type: object" so making that explicit in the API definition should not be flagged as a breaking change.

[jianyexi]

With 'type:object' and without 'type' have different meaning, as without 'type:object' indicates that the model is any type.

[mikekistler]

I don't disagree with your statement, but I believe that if type is not specified and properties is present, then the schema cannot be "any type" -- it must be an object. That is the case I'm describing here.

[jianyexi]

I don't disagree with your statement, but I believe that if type is not specified and properties is present, then the schema cannot be "any type" -- it must be an object. That is the case I'm describing here.

In the below example, the model can be either an object with properties or any other type like string, int . This contract is instituted by autorest

"Foo" : {
"properties": {
 "propertyA": {
   "type":"string"
 }
...
}
}

[mkistler]

I stand corrected! Apparently "properties" only applies if the instance is an object. Wow JSON Schema is a strange language.