Replies: 3 comments
-
I've also opened a new issue with YAML spec itself, related to their examples for JSON Schema ruleset being misleading/wrong. |
Beta Was this translation helpful? Give feedback.
-
@char0n I'm not sure anyone here understands YAML deeply enough to know what any of this is about. See also issue #2951, where we also couldn't quite figure out what was being proposed or what is needed. If you can find a YAML expert to sort this out that would be helpful |
Beta Was this translation helpful? Give feedback.
-
@char0n It's important to note that the spec does not require parsing with the JSON schema ruleset. It just says you can't use a tag that is not defined by the JSON schema ruleset. Whether intentional or not, it's an important distinction as many YAML parsers do not implement specific YAML schema parsing modes. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi everybody,
I'd like to open discussion on clarifying the following OpenAPI excerpt (3.x.y):
specifically
1. we can say that this sentence means that tag resolution is driven by JSON Schema ruleset (and its extended list of regular expressions), it effectively means that following YAML is invalid:
It can only be valid if we define it like this:
2. we can say that this sentence means that we can basically use any YAML Schema derived from JSON Shema ruleset (like Core) as long as the tag names are the same as in JSON Schema regardless of the resolution rules and extended list of regular expressions; which makes following valid YAML
I'm assuming it was intended to target option 1.? As we probably want to retain all the info during the YAML/JSON round-trips (but I might be completely wrong)
becomes
and not
{"key": false}
Beta Was this translation helpful? Give feedback.
All reactions