The value of the examples annotation should be an object or an array

[K-Adam]

Json schema has examples annotation, which comes handy, when I would like to run a mock server for my api.

Unfortunately the spec states, that the value of examples keyword MUST be an array:

{
  "title" : "Match anything",
  "description" : "This is a schema that matches anything.",
  "default" : "Default value",
  "examples" : [
    "Anything",
    4035
  ]
}

I suggest to enable objects as well, so each example could be referenced by name:

{
  "title" : "Match anything",
  "description" : "This is a schema that matches anything.",
  "default" : "Default value",
  "examples" : {
    "stringValue": "Anything",
    "integerValue": 4035
  }
}

This change could make the construction of complex examples ( like a list ) much simpler.

[handrews]

Another option would be to add a namedExamples or exampleObject keyword to make things a bit easier on the statically typed language implementations and not break existing implementation assumptions.

[karenetheridge]

Now that dependencies has split into dependentRequired and dependentSchemas, and items into prefixItems and items, do we have any polytyped keywords remaining? ..other than examples and const, which can be any type at all...

[gregsdennis]

to make things a bit easier on the statically typed language implementations - @handrews

This isn't an issue in my .net implementation. I just save the JSON model which can represent the appropriate types.

[handrews]

@karenetheridge type is the other one.

The rationale for splitting dependencies wasn't about the types, though, but about separating the applicator and assertion functions. Since the two syntaxes corresponded to two different sorts of functionality it made a lot of sense to split. type really is doing the same in both syntaxes, it's just allowing you to leave off the array markers if there's only a single type.

[handrews]

(idk why I felt compelled to go all history lesson on dependencies 🤷 )

[gregsdennis]

We expect nothing less from you @handrews.

[K-Adam]

@handrews namedExamples would be perfect

[gregsdennis]

In 2020-12, we changed the behavior of unknown keywords to be included as annotations rather than being ignored.

This means that you can add namedExamples to any 2020-12 schema, and it should be included in the output as an annotation along with its value.

There's no need to explicitly defined the keyword.

[jdesrosiers]

I agree with @gregsdennis, a new keyword is not necessary, however I could see this keyword as part of a vocabulary of keywords that support mock servers or something similar.

[handrews]

I'm going to move this over to the vocabularies repo. As noted, there is no longer a need to add a new keyword to the specification get the basic annotation behavior, but a vocabulary that defines this would be useful for interoperability. As explained in PR json-schema-org/json-schema-spec#1294, implementations should be able to trivially support annotation-only vocabularies when they are included as optional (false in $vocabulary).