Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

YAML KeyValuePair - Key can be any kind, not just scalar #130

Open
char0n opened this issue Oct 15, 2020 · 2 comments
Open

YAML KeyValuePair - Key can be any kind, not just scalar #130

char0n opened this issue Oct 15, 2020 · 2 comments
Labels
ApiDOM enhancement New feature or request YAML

Comments

@char0n
Copy link
Member

char0n commented Oct 15, 2020

Key in YAML can be represented by any kind - Scalar, Sequence and Mapping. As JavaScript doesn't allow that we have to do what other libraries do - convert the non-string Key into string key. We have three options for conversion:

1.) Using Symbol.toStringTag

using Object.prototype.toString to get a string representation of an object or an array.

js-yaml is using this approach.

---
? [ foo, bar ]
: - baz
? { foo: bar }
: - baz
  - baz

will become

{ "foo,bar": ["baz"], "[object Object]": ["baz", "baz"] }

2.) Using Original YAML fragment

{[1, 2]: many}

will become

{ '[1, 2]': 'many' }

yaml library is using this approach as default behavior.

3.) Using Map Object for mapping

With new JavaScript Map type, any value (both objects and primitive values) may be used as either a key or a value.

That means that we can do the following:

{[1, 2]: many}

will become

Map{ [1, 2] => 'many' }

yaml library is using this approach as opt-in behavior with mapAsMap option.

Refs #1

@char0n char0n added ApiDOM enhancement New feature or request YAML labels Oct 15, 2020
@webron
Copy link

webron commented Oct 15, 2020

Not sure about AsyncAPI, but for OpenAPI this is not needed. From http://spec.openapis.org/oas/v3.0.3#format:

Keys used in YAML maps MUST be limited to a scalar string, as defined by the YAML Failsafe schema ruleset.

@char0n
Copy link
Member Author

char0n commented Oct 15, 2020

Yes both specifications doesn't allow that, but it doesn't change the situation. We have to be able represent this information on CST/AST level so that we could validate. Then we should be able to encode fields like that into ApiDOM so that one field defined like that doesn't stop us from generating full ApiDOM tree and possibly rendering it in editor view. Having fields defined in this way should trigger validation WARNING and not validation ERROR. This issue is about choosing strategy to use when situation like that happens.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ApiDOM enhancement New feature or request YAML
Projects
None yet
Development

No branches or pull requests

2 participants