Add a keyword for autocomplete suggestions

[Chi-teck]

IDEs use "enum" property for autocompletion but in some use cases a property must accept arbitrary data.

Current workaround. Works fine in PhpStorm and likely in other JetBrains products. Though the violation message is a bit messy. Might be improved some day with #396.

"data": {
    "anyOf": [
        {
            "enum": ["public", "private", "temporary"]
        },
        {
            "type": "string"
        }
    ]
}

However it is too verbose and still looks a hack.

If we have a dedicated keyword for suggestions the above schema would look like follows.

"data": {
    "type": "string",
    "suggestions": ["public", "private", "temporary"]
}

[kylef]

Perhaps the already existing examples could be used for this purpose?

{
  "type": "string",
  "examples": ["public", "private", "temporary"]
}

[Chi-teck]

I think examples have slightly different meaning.

[Chi-teck]

Alternatively we could extend examples keyword definition.

[Relequestual]

Thanks for your suggestion. I can certainly see it would be useful to have keywords that enable more things for IDEs.

However, this falls outside of the remit for core and validation.

We recognised this and added “vocabularies” in draft-8! 🙌🤯thank @handrews !

This will enable and encourage communities that want new keywords for specific purposes to band together and create new sets of keywords.

For now, I’m going to close this issue. Maybe it will migrate to a new repo some time soon!

[awwright]

This seems slightly outside the scope of JSON Schema because both values are equally "valid". What you're looking to indicate is that some special values for the string have exceptional behavior. You might look at implementing these as a separate schema ("this is the subset of values that have a special behavior"), and/or as an annotation keyword.

But in any event, going too far in this direction means turning JSON Schema into a programming language—you're actually talking about "when this value is recognized, perform this action" and that's somewhat of outside the scope.

[awwright]

@Chi-teck Also, other pattern languages such as ABNF frequently define patterns similar to the one you posted. For example, HTTP/1.1 defines the Transfer header like this:

transfer-coding    = "chunked" / "compress" / "deflate" / "gzip" / transfer-extension

which is pretty much the same thing you posted: "accept one of these literal values, or anything else" which might be redundant at first glance, except for the fact that the provided literal values triggers special behavior.