OpenAPI.XML legacy defaults don't survive a JSON round trip

[Joseph-Cursio]

Using the attribute:/wrapped: initializer with both flags left at their defaults produces a value that doesn't survive an encode/decode round trip (seen on main):

let xml = OpenAPI.XML(name: "hello", attribute: false, wrapped: false)
let decoded = try JSONDecoder().decode(OpenAPI.XML.self, from: JSONEncoder().encode(xml))
// decoded != xml

The initializer builds .legacy(attribute: false, wrapped: false). Encoding that writes no keys, and decoding no keys lands on the (false, false, nil) case, which sets structure to nil. Since == compares structure, the decoded value is unequal to the original.

Relatedly, OpenAPI.XML(name: "hello", nodeType: nil) encodes to identical JSON but compares unequal to the value above.

Both fields default to false in the spec, so "omitted" and "present and false" describe the same document. That suggests the legacy initializer should produce nil when neither flag is set. The alternative — having the decoder reconstruct .legacy(false, false) — would just move the asymmetry onto the nodeType: nil spelling instead.

OpenAPIKit30 isn't affected, since it stores attribute/wrapped as plain Bools.

Happy to open a PR for the first approach if that's the direction you'd prefer.

Found with AI assistance (Claude Code), via a generated round-trip property test; I've reviewed the analysis and am happy to discuss it.

[mattpolzin]

Thanks for the report. Let me take a look at the code before you move on this. Having encode, decode round trips produce the same result is a goal of OpenAPIKit but not a mandate -- I am ok with opinionated decisions being made sometimes. In this case, I maybe vaguely recall the decision being intentional so that the legacy structure was supported but actively discouraged by promoting it to a modern alternative on decode. Equality checks don't need to be equivalency checks, but again I do agree that the best ergonomics are that a value is equal to itself after going through an encode and a decode.

[mattpolzin]

Alright, I've revisited this after looking over the code again. The behavior as it stands is intended. Despite the fact that I would very much like encode/decode to be inverse operations, there are a few times in OpenAPIKit where I've felt that other properties are more beneficail. In this case the justification is the combination of:

• I want to support explicitly representing the legacy combinations of properties without encouraging it.
• I want to decode documents under the assumption that they are non-legacy if possible to represent them as such.
• I want to be opinionated about preferring non-legacy combinations when possible.
• I want to encode both legact and non-legacy combinations as omitting values that are their defaults.

In the end, you do end up with some situations where an explicitly legacy representation in-code may be promoted to a modern representation through encode/decode but this is favorable nonetheless because the OpenAPI documents are equivalent, the in-code constructions just aren't identical.