Post by nschellenberger on Apr 23, 2023 19:16:27 GMT
A couple more little oddities picked up by accident during our development of generic tooling and verification. I'm afraid I lack the resources to root cause these in the generator tooling since they don't actually impact our specific use cases--we just noticed them in passing.
These will end up being functional problems for anyone using a schema-driven client e.g. a generic OpenAPIv3 client et al.
For the Outlet and OutletGroup PowerControl Actions, if I had to hazard a guess, I suspect the generator's name lookup for the parameter types of request bodies is not quite right. Perhaps around the time that Outlet and OutletGroup were updated to use Circuit.PowerState the lookup code wasn't updated to look into namespaces other than that of the current schema?
That being said, I wonder also if there is a second, independent semantic/refactoring problem in this very specific case of PowerState and the CSDL ought to be referring to Resource.PowerState in the first place? Ditto perhaps the PowerState Property in the body which currently has type Circuit.PowerState? (Or perhaps there are subtle backward compatibility constraints here?) Clearly there was/is various refactoring going on here that is well outside of my wheelhouse, so I probably have the wrong end of the stick again.
For Drive, I would also suppose (but again do not know with certainty) that the name lookup is also not quite right--although perhaps for different reasons. It would seem that the reference ought to be to e.g. Drive.v1_1_0.json#/definitions/Operations i.e. it looks like the wrong namespace was resolved. Oddly, in 2022.3 Drive_v1.xml schemas 1.1.3 and 1.2.1 both mention changing Operations to use the unversioned definition but the actual definition in 1.1.0 for Operations is Type=Collection(Drive.v1_1_0.Operations). (I have not gone spelunking through the previous versions to see what the actual textual changes were, so perhaps something else was meant by those comments rather than specifically the Type of the Operations Property.)
These will end up being functional problems for anyone using a schema-driven client e.g. a generic OpenAPIv3 client et al.
- Outlet and Outlet Group Action PowerControl Parameter PowerState ends up generating $ref to non-existent targets
- Outlet JSON (various) to Outlet.json#/definitions/Outlet_PowerState
- Outlet YAML (various) to Outlet.yaml#/components/schemas/Outlet_PowerState
- OutletGroup JSON (various) to OutletGroup.json#/definitions/OutletGroup_PowerState
- OutletGroup YAML (various) to .../OutletGroup.yaml#/components/schemas/OutletGroup_PowerState
- Drive Property Operations ends up generating $ref to non-existent targets
- Drive JSON (various) to Volume.v1_0_0.json#/definitions/Operations
- Drive YAML (various) to Volume.v1_0_0.yaml#/components/schema/Operations
For the Outlet and OutletGroup PowerControl Actions, if I had to hazard a guess, I suspect the generator's name lookup for the parameter types of request bodies is not quite right. Perhaps around the time that Outlet and OutletGroup were updated to use Circuit.PowerState the lookup code wasn't updated to look into namespaces other than that of the current schema?
That being said, I wonder also if there is a second, independent semantic/refactoring problem in this very specific case of PowerState and the CSDL ought to be referring to Resource.PowerState in the first place? Ditto perhaps the PowerState Property in the body which currently has type Circuit.PowerState? (Or perhaps there are subtle backward compatibility constraints here?) Clearly there was/is various refactoring going on here that is well outside of my wheelhouse, so I probably have the wrong end of the stick again.
For Drive, I would also suppose (but again do not know with certainty) that the name lookup is also not quite right--although perhaps for different reasons. It would seem that the reference ought to be to e.g. Drive.v1_1_0.json#/definitions/Operations i.e. it looks like the wrong namespace was resolved. Oddly, in 2022.3 Drive_v1.xml schemas 1.1.3 and 1.2.1 both mention changing Operations to use the unversioned definition but the actual definition in 1.1.0 for Operations is Type=Collection(Drive.v1_1_0.Operations). (I have not gone spelunking through the previous versions to see what the actual textual changes were, so perhaps something else was meant by those comments rather than specifically the Type of the Operations Property.)
