Still Kinda Supporting Unknown Keywords - A call for proposals

[gregsdennis]

DECISION: The proposal to use a prefix was the much preferred option. After hosting a survey, the results indicated that most users like the idea of using x- as that prefix.

Prefix	Responses
x-	17
@	12
*	12
!	6
#	4
Others	2
Total Responses	53

Thank you to everyone who commented below and to those who participated in the survey.

---

Previously, on JSON Schema Discussions:

• Dropping support for unknown keywords was proposed
• We determined that we can't promise no breaking changes without dropping such support.
• We also gathered feedback from the community that dropping such support in order to achieve stability between versions is understandable, but they expressed that they'd like to have some sort of migration support in documentation and/or tooling.

Now we need to figure out how to support the transition. Questions to answer here:

Is there a way that unknown keywords can still be supported?

In the proposal, Henry identified four categories for "unknown" keywords:

• a keyword is supported if the implementation understands to run a specific piece of code for it
• a keyword is understood if the implementation knows what vocabulary it comes from, but doesn't have specific code for it
• a keyword is unknown if the implementation cannot figure out whether it comes from any particular vocabulary or not
• a simple value annotation (SVA) keyword is one that unconditionally uses the exact keyword value as the annotation value

This discussion will focus on SVAs since these are the keywords that can reliably be supported by implementations without needing custom code. As Henry stated in his discussion:

SVA-only vocabularies are central to the question of removing non-vocabulary keywords, so they are the main thing to worry about here.

(He also requested that solutions be discussed elsewhere. This discussion is that elsewhere.)

Despite the request, several ideas did crop up:

• Define a convention that SVA keywords begin with @ (or some other such symbol). (This would also require the contrapositive: that non-SVA keywords must not begin with @.)
• Inlined vocabularies to define SVA keywords just for that meta-schema.
• A new keyword that identifies SVA keywords just for that schema.

The proposed solution in the opening comment has merit but is more of a long-term idea, and I think it requires more thought. In the meantime, we should look for simpler solutions.

I'll start threads for these so that we can have more targeted discussions for each of them. Please feel free to vote (👍/👎) for your preference at the root of the thread or leave another idea.

---

I think it's also important not to lose track of these things, which came up in that discussion.

Several of this proposal's assumptions are now being tracked or addressed directly:

• Better explanation of optional vocabularies is addressed by PR Normative language for "$vocabulary" json-schema-spec#1295
• Strengthening the requirements around optional vocabularies is being tracked as issue Strengthen requirements around optional vocabularies json-schema-spec#1300
• Strengthening the requirements around dialect/vocabulary determination is being tracked as issue Strengthen "$schema" + "$vocabulary" requirements json-schema-spec#1301

Related: json-schema-org/json-schema-spec#1365 and associated PR json-schema-org/json-schema-spec#1244 (@awwright).

[gregsdennis]

Solution proposal:

Define a convention that SVA keywords begin with @ (or some other such symbol). (This would also require the contrapositive: that non-SVA keywords must not begin with @.)

This would allow users to include ad-hoc SVAs without needing to create a vocabulary to contain them, similarly to how they use unknown keywords now.

[gregsdennis]

# is used in many programming languages to indicate a comment, which could be a cause for confusion.

That may actually be advantageous for us because we're saying we won't "process" them; we just collect their values.

[sandrina-p]

Hi! Just wanna add that in the company I work at (Remote.com), we are using the prefix $ in almost every custom keyword for the same reason: To easily distinguish between native keywords and in-house keywords/specs. Personally, I don't have any preference between $ or @, so I believe we can easily refactor it to whatever your final decision is :)

Update: And yes, we have a meta json-schema to annotate those in-house keywords :)

[sandrina-p]

What about the prefix underscore _?

[gregsdennis]

Underscore is another option, yes, but I suspect that some people might use that for legitimate keywords. (I'm thinking serialization scenarios. In .Net, it's common to underscore-prefix private fields, which also sometimes get serialized.)

[sandrina-p]

@gregsdennis I'd prefer the prefix _ for simplicity in JavaScript. With it we can keep the dot notation.
eg properties.salary._currency vs properties.salary["@currency"].

[gregsdennis]

Solution proposal:

Inlined vocabularies to define SVA keywords just for that meta-schema.

The API for this isn't really defined, but as a quick thought, maybe something like this could work:

{
  ...
  "$vocabulary": {
    "http://my.vocab/svas": [ "foo", "bar", "baz" ],
    ...
  }
  ...
}

This says a vocabulary identified as http://my.vocab/svas defines the keywords foo, bar, and baz.

The advantage here is that the definition for SVAs stays within the vocabulary system.

[Relequestual]

I am somewhat of in favour of this.
It does make it a little more complicated to implement, however it would avoid the whole "you accidentally typoed that key there" situation, which is one of the drivers for this change, even if a lesser one.

It would be nice to be able to give people the confidence that they haven't mistyped ANY keys in their schema.

[jdesrosiers]

To me, the problem with this is that it would require a custom meta-schema. Someone who just wants to add a simple one-off annotation shouldn't need to put in that much effort.

However, I do think that a vocabulary description format is important to address at some point in the future and it should include some way to declare that a keyword is an SVA.

[gregsdennis]

Solution proposal:

A new keyword that identifies SVA keywords just for that schema.

{
  ...
  "$annotations": [ "foo", "bar", "baz" ],
  ...
}

This is similar to the ad-hoc vocab but less verbose.

[gregsdennis]

Correct, it was discussed over several OCWM calls (the two most recent are probably more pertinent)

[gregsdennis]

The "data" keyword concept is needed because if the meta-schema is going to validate that unknown keywords are invalid, it needs to know to skip the ones listed in an "ignored" list. But that list is contained in the schema that's being validated, not in the meta-schema. The meta-schema has to reference the data in the schema in order to know what keywords to allow.

[sandrina-p]

So, would that data keyword be the same as the ignore proposed above, or is it something different? Those custom keywords would still require a prefix (eg @) to avoid future conflicts, right?

[gregsdennis]

No. data is a special keyword that allows definition of the schema based on the contents of the data it's validating. Please have a read of the docs for my vocab that I linked for how it works.

data (or something like it) is needed to make this option work. Since we don't have data in the base spec, we can't do this option.

[awwright]

Imagine you have a custom keyword "currency" in a json schema
And tomorrow JSON Schema introduces this official new keyword "currency" with a completely different purpose

This is why you should not define custom keywords in the standardized namespace, you should use a vocabulary that distinguishes your use from a potential standardized use.

[jdesrosiers]

Solution proposal:

Define a configuration option that allows users to declare whether they want to allow unknown keywords.

This is similar to how format assertions can be enabled via a configuration option.

[jdesrosiers]

I'm not advocating for this solution, just including it for completeness.

[gregsdennis]

We would need to specify that this configuration would need to default to off: disallow unknown keywords.

[Relequestual]

I'm somewhat against this as a solution.
In the case of AJVs "stirct mode", I've seen ecosystem type tooling which used AJV 7 layers of dependencies deep, but passed through a user provided schemas. It was impossible to pass down configuration all the way down. This is problematic.

[SorinGFS]

@Relequestual

It was impossible to pass down configuration all the way down. This is problematic.

Yes, that's due to reference system, settings are set at first level (those with $) then all subsequent schemas need to comply, AFAIK there is no posibility to override the lower level settings. In a regular project on contrary we can set 'use strict' on every individual file, there is no such a strict rule to set use strict at the project root level. That's why I think many of the problems are actually due to the reference system.

[Relequestual]

Yes, that's due to reference system...

No, this is nothing to do with referencing. It is to do with dependencies in libraries.

[karenetheridge]

I have no objection to the next version disallowing unknown keywords (and including "unevaluatedProperties": false in the main metaschema) as long as we allow and ignore x-* keywords (that is, there is an explicit "patternProperties": { "^x-": true } in the main metaschema as well) and we specify that these properties MUST NOT do anything at all except produce annotations as unknown keywords did in 2020-12.

That gives everyone a place to put their "x-author": "ether" markup without getting in the way of custom vocabularies (which must avoid the use of x-*), or by implying that their custom keywords actually do anything.

Also, this is what is done in OpenAPI v3.1's custom json schema dialect. (apologies; I was looking at a third-party extension of the standard OpenAPI schema. But it is true that in OpenAPI documents themselves -- the bits that aren't json schemas -- unknown keywords are not allowed, with the exception of those starting with x-.)

[SorinGFS]

Like you said, it's the users who provide pressure to the implementations that gets them to update. It's been my experience that most implementations won't update without that pressure.

Well, sadly that's true, that's why users are stuck in lower versions, but still they know that they cannot use the newest specs using their current implementation...

[Relequestual]

@SorinGFS, you've missed the neuance here. We're talking about keywords not yet defined. You can't detect for what is not knowable.

[jdesrosiers]

@Relequestual

If each new snapshot release doesn't have its own dialect URI, we're going to get "surprises", and that's very undesierable.

I agree that surprises are undesirable, but not that allowing unknown keywords in the meta-schema creates surprises.

If those meta-schemas don't have identifiers, there will be a raft of implementations with different version support, but no way to tell which meta-schema is being used.

The point is that it doesn't matter which meta-schema is being used because they are all compatible. You can't get that property if you disallow unknown keywords in the meta-schema.

Based on what I'm reading from your suggestion, people will use the "stable" meta-schema in one implementation and get told their schema is valid, and use it in others and get told their schema is not valid

No, it's the opposite. If you allow unknown keywords in the meta-schemas, users will always get the same result no matter what version of the meta-schema they are using. If you disallow unknown keywords in the meta-schemas, different implementations will tell you that your schema is valid or invalid.

Let's say a user has a schema using a 2025 keyword. They try to use that schema in an implementation that only supports up to 2024. If the 2024 meta-schema disallows unknown keywords, the user would be told that the schema is invalid. That's not correct because if the user then uses that same schema in an implementation that does support 2025, it will work fine. The schema wasn't invalid, the implementation just didn't support all the keywords the schema uses. In that scenario, the user got conflicting information about their schema. The first implementation said the schema was invalid, the second said it was valid.

Now, let's consider the same scenario where meta-schemas allow unknown keywords. In the first implementation, the schema would pass the 2024 meta-schema and the implementation would attempt to evaluate the schema. When it encounters the 2025 keyword it doesn't support, it would respond with an error stating that it doesn't know the keyword. The second implementation will understand the keyword and process the schema without error. Unlike the previous case, we don't have the two implementations providing conflicting information about whether or not the schema is valid.

However, it would be possible for two implementations to have different ideas about whether a schema is valid or not. If a user used a 2025 keyword wrong, the 2024 meta-schema wouldn't be able to detect that. That shouldn't be a problem because the 2024 implementation would still end up with an error result. The result would be an unknown-keyword error rather than an invalid-schema error. Disallowing unknown keywords in the 2024 meta-schema would have resulted in an invalid-schema error, which is correct, but for the wrong reason. The meta-schema doesn't actually know if the 2025 keyword was used improperly, it just got lucky.

Remeber, the meta-schemas must prevent additional keywords.

This makes me concerned that we aren't talking about the same thing. Implementations must error on unknown keywords, but whether or not meta-schema should prevent additional keywords is what this discussion is about, it's not a given.

There would be no way for a schema author to know if the library support is out of date, or if they really are using a keyword that isn't defined in JSON Schema.

Yes, but there's no way an implementation could know that information. An implementation can't know what might exist in the future. I'm sure I'm missing some crucial bit of context to understand the point you're making here.

We know VSCode for example is outdated and doesn't properly support new versions of JSON Schema. Previously, I requested adding a warning when support was behind latest. Without that, people would be trying things and thinking it worked and was valid, when it wasn't.

The experience would be similar. The only difference would be that users would be told VSCode doesn't understand the keyword they used rather than VSCode doesn't support some version of JSON Schema. I think that would be a better experience actually. They get precise information about what when wrong rather than a blanket statement that forces them to look up what exactly they used in their schema that isn't supported.

With ECMAScript, if you want to use features from a specific version, you have to declare the version you're using

That's not correct. You don't declare what version of ECMAScript your code is written for. In fact, there isn't even a way to do so (no equivalent to $schema). An ECMAScript interpreter executes your code and will produce an error if it encounters something it doesn't understand. The version of ECMAScript is just for implementations to indicate what features they support. What I'm suggesting works exactly like ECMAScript. I'm still on that path like I always have been.

You need to declare a version for some kinds of tooling, but that's a different thing. For example, you would tell a transpiler what version you want to downgrade your code to so it has a greater chance of working with any implementation.

[gregsdennis]

Okay, I see what you're talking about. You're talking about whether we enforce disallowing unknown keywords with an unevaluateProperties: false in the meta-schema.

That's a completely different conversation to the one we're having here (although Karen mentioned it in her opening comment), and it should be discussed, but somewhere else. I've opened an issue in the spec repo to discuss that since it will need a PR.

I want to return focus to how we allow SVAs in this discussion.

[Relequestual]

@jdesrosiers It looks like we have some very different expectations based on different assumptions, most of which I was sure were decided and agreed on. It's going to take quite a lot of effort to unpick ther assumptions we've both made, and dig through previous discussions to find where we thought things were agreed. (I estimate 1-3 days to properly unpack this, and I'm on limited time for the next two weeks, just as an FYI. So we will do it, but I'm likely to be a little slower than I'd maybe like.)

@gregsdennis while I agree with your assessment, I think disallowing unknown keywords without doing so via the meta-schema defeats the point. I feel very strongly doing so via the meta-schema is absolutley critical. Looks like we have much to discuss, and maybe that new issue is a better place than here.

[jdesrosiers]

We've settled on the idea of using a prefix to allow unknown keywords, but there's some disagreement about exactly how that mechanism would work. Let's work this out.

@gregsdennis originally proposed the prefix this way,

Define a convention that SVA keywords begin with @ (or some other such symbol). (This would also require the contrapositive: that non-SVA keywords must not begin with @.)

I suggested the following,

I would define this a little differently. Any keyword that starts with @ MUST be treated as an SVA that is not a part of any vocabulary. That means that vocabularies can't define a keyword that starts with a @. So, @ doesn't mean it's an SVA, it means it's an SVA without a vocabulary. Keywords like title, which is an SVA, would not be renamed to @title because it's part of the meta-data vocabulary.

@karenetheridge has a similar view,

That gives everyone a place to put their "x-author": "ether" markup without getting in the way of custom vocabularies (which must avoid the use of x-*), or by implying that their custom keywords actually do anything.

(I'll present my case later. This is just promoting the conversation for now)

[jdesrosiers]

This discussion takes place precisely because many have keywords in the schema on which their code is based!

No, that's not what this discussion is about. The vocabulary system already exists to support that use case. This discussion is about allowing people to use custom keywords that are inconsequential enough that defining a vocabulary for them doesn't make sense. It's for things like an @author keyword that would allow readers to see who they can contact if they have questions.

[karenetheridge]

There's all kinds of reasons why you might want to do this. Consider a custom keyword that has a particular meaning for your tooling, but is only applicable to your local usecase and you'd never want to publish it as a "standard", and it's not formal enough to be worth creating a vocabulary for (or, the schema author doesn't know about vocabularies and isn't interested in learning). I have several examples of this in my local schemas, such as a keyword that lists "systems that call this API", and a keyword that lists potential side effects for an API. This information is aggregated by a local tool for augmenting the machine-generated documentation.

Or, there's some piece of information I want to note in the schema but no tool uses it - I use "x-note" or "x-important" all the time to include information I want a future schema author to see.

[SorinGFS]

@jdesrosiers
I don't think you are on the same page with @gregsdennis on this one. Here is what it sais bellow:

We prefer to not break our users' workflows.

[SorinGFS]

@karenetheridge

I have several examples of this in my local schemas ...

Yes, that is your use case, but I read a lot of schemas last month and I saw plenty of unknown keywords, I'm pretty sure that maybe 9 out of 10 of them are not just annotations of different kinds...

[SorinGFS]

@jdesrosiers

No, that's not what this discussion is about. The vocabulary system already exists to support that use case. This discussion is about allowing people to use custom keywords that are inconsequential enough that defining a vocabulary for them doesn't make sense. It's for things like an @author keyword that would allow readers to see who they can contact if they have questions.

If the goal is to solve only that problem, I think it's root comes from the fact that $comment takes only one value. This can be solved in various ways:

{
    "$comment_author": "John Doe",
    "$comment_email": "[email protected]",
    "$comment_version": "1.2.3",
    "$comment_0": "some text",
    "$comment_1": "next comment line",
    "$comments": [ "some text", "next comment line" ],
    "$comment*": "this would be the general syntax, basically allowing $comment keyword to be extended as needed"
}

Is even possible to define a $comments keyword as object with desired properties.

But only by solving this problem I don't think there will be too many satisfied users. I think this problem is a marginal one, the real problem being the need to rewrite the software for relocating keywords that are no longer accepted in the schema.

[SorinGFS]

This discussion is going so wrong... Everyone here says what they would like, but no one says what they would not like and why! The main preference of the json schema team is known: removing support for unknown keywords entirely! The discussion fails to attract answers from those who would be affected by this decision. Why would the json schema team bother to offer a solution to something that apparently nobody cares about? The json chema team is trying to offer a solution to what?

@jdesrosiers

There's also the case of people simply using prefix keywords as a way to avoid the vocabulary system and then later realize there are benefits to formally defining them.

I think would be kind of impossible to understand the benefits of vocabularies with this documentation:

Vocabularies
New in draft 2019-09
Documentation Coming Soon

... same goes for:

Extending Recursive Schemas
New in draft 2019-09
Documentation Coming Soon

... as for $dynamicRef is not even in the index despite the fact that understanding json-schema refers to draft/2020-12 and the search only returns a single mention...

There are still a few topics like these, and I think it's no coincidence that these topics are the most misunderstood and unused...

[gregsdennis]

The main preference of the json schema team is known: removing support for unknown keywords entirely!

This is a mischaracterization of our intent.

We prefer to not break our users' workflows. To get there, we have to disallow unknown keywords in general.

This discussion was raised to see if there are solutions that can still provide similar functionality, even if it's not 100% compatible with the old way.

The discussion fails to attract answers from those who would be affected by this decision.

We have made many efforts to invite others to this discussion as well as posting links and opening the same discussion on other sites and creating and publishing surveys to get the public (users) preference.

Why would the json schema team bother to offer a solution to something that apparently nobody cares about?

The responses and reactions we've seen and received to my blog post about our decision indicate that many people do actually care about this.

I think would be kind of impossible to understand the benefits of vocabularies with this documentation...

If your complaint is that the documentation is outdated, we welcome contributions. We're a small team, many of us (all of us until recently) working in our free time to make something of this specification.

[SorinGFS]

If your complaint is that the documentation is outdated, we welcome contributions. We're a small team, many of us (all of us until recently) working in our free time to make something of this specification.

I am not reproaching anyone, I am just noticing a state of fact. It would be quite difficult to contribute to something I don't understand... 😄

[SorinGFS]

The responses and reactions we've seen and received to my blog post about our decision indicate that many people do actually care about this.

I have not the slightest doubt about the fact that many people care about this subject, only that their opinions did not reach this discussion! This is the place where they should not necessarily show their preferences, but show their reservations about some proposals!

[jdesrosiers]

Why would the json schema team bother to offer a solution to something that apparently nobody cares about?

Actually, it was originally my opinion that we shouldn't allow unknown keywords and just follow up later with trying to make the vocabulary system easier to use. It was feedback from the community that convinced me that there is a need for a solution for this.

I think would be kind of impossible to understand the benefits of vocabularies with this documentation...

We're aware that the documentation is lacking and that the vocabulary system needs to be better. You're right to be frustrated about that, but that shouldn't impact what decisions we make about this feature. The documentation will not always be missing.

[benjagm]

Hi everyone! Sharing here this discussion from the JSON-LD \ YAML LD discussions on similar topic. They suggest a new elegant alternative solution worth exploring.

json-ld/yaml-ld#51

Thanks Orie for sharing this.

[gregsdennis]

I really think this is intriguing: define a new keyword (e.g. $sigil) that indicates the prefix for the local schema to use. We can even default to @ as described in another thread.

This gives the author the opportunity to use another prefix if they wish, which may satisfy the many different preferences we've discovered.

I also don't think it would be too difficult to implement.

The only question is scoping. What does "local" mean in my description above? I don't think we can identify the document since we're using the JSON data model rather than the text. Maybe schema resource, or perhaps even dynamic scope?

[gregsdennis]

It was pointed out in the OCW meeting that $sigil would not be supportable by the meta-schema if the meta-schema is forbidding unknown keywords.

For example, if a schema uses "$sigil": "&" then any keyword with & should be acceptable, but the meta-schema wouldn't be able to permit those keywords without first seeing what the value of $sigil is. That kind of operation requires a data keyword or similar functionality (even just the data keyword alone wouldn't support it).

[jviotti]

Not sure if this was proposed yet (the discussion is already too long), but just to throw it out there for the record: the Core vocabulary defines a keyword for reserving a location: $defs. What about introducing a new keyword in Core whose entire purpose is to be a container for unknown keywords. Essentially, set it to anything you want:

{ "$extra": { anything you want here } }

Then we can avoid the prefix character discussion altogether.

[gregsdennis]

I think there might be some confusion between this and $comment. Whereas we would want annotations from this (more below), $comment specifically is to be ignored, not producing an annotation with its value.

Secondly, keywords can produce at most a single annotation. The entire content of this keyword would have to be the annotation.

In the output, this looks like

{
  "valid": true,
  "evaluationPath": "",
  "schemaLocation": "https://json-everything.net/febeae0be0",
  "instanceLocation": "",
  "annotations": {
    "$extra": {
      "annotation1": "test",
      "annotation2": 5
    }
  }
}

as opposed to

{
  "valid": true,
  "evaluationPath": "",
  "schemaLocation": "https://json-everything.net/09decc05dc",
  "instanceLocation": "",
  "annotations": {
    "@annotation1": "test",
    "@annotation2": 5
  }
}

[karenetheridge]

Not sure if this was proposed yet (the discussion is already too long), but just to throw it out there for the record: the Core vocabulary defines a keyword for reserving a location: $defs. What about introducing a new keyword in Core whose entire purpose is to be a container for unknown keywords. Essentially, set it to anything you want:

{ "$extra": { anything you want here } }

I like this, but it can be orthogonal to the concept of an ignored prefix. I would support the addition of an $extra keyword to the spec that essentially acted like $comment (put anything you like in here, but don't create an annotation for it) but whose value could be any type, not just a string.

[awwright]

I think this is confusing two different concepts... first is the ability to store semantically meaningful user content (as opposed to an unmeaningful comment); second is the ability to specify that a keyword is not an assertion (but maybe an annotation).

For example, you can have published standard keywords that don't validate, but that annotate; and you can have user keywords that make assertions that must not be ignored.

Can you explain how this supports these two examples?

[SorinGFS]

Yet another idea...

How about ignoring keywords based on a set of rules, like this:

• ignore all keywords not starting with $ or [a-z] pattern
• ignore all keywords containing :, /, \, |, ^, *, +, ?, <, [, (, {, ., ,, ; space, and $ not as first char
• ignore all keywords specified in $ignored array

[awwright]

ignore all keywords not starting with $ or [a-z] pattern

This would put us in a better situation than where we are now, where at least some keyword names are "must-understand" instead of none. ...But, I think we can just skip to the step where all keywords are assumed to be validation keywords unless specifically marked otherwise. How to mark a keyword as "not validation" is what's at issue.

ignore all keywords containing :, /, \, |, ^, *, +, ?, <, [, (, {, ., ,, ; space, and $ not as first char

This is too many keywords ignored... the purpose here is reserve a large number of keywords, then release them when we need to define a validation (or other must-understand) keyword. This would mean that URIs as keywords would be ignored.

ignore all keywords specified in $ignored array

This is more complicated. There is one variation of this that I like which is "this keyword is the same as that keyword"—so if a user keyword or vendor keyword gets standardized with a different name, you can say "border-radius is also known as -moz-border-radius" (to borrow an example from CSS) and then older user agents will handle a newly standardized name correctly.

[SorinGFS]

This is too many keywords ignored... the purpose here is reserve a large number of keywords, then release them when we need to define a validation (or other must-understand) keyword. This would mean that URIs as keywords would be ignored.

Still, I think there are enough options left for keywords, I think that an analogy can be made with the existing options in programming languages for defining variables. I think that json-schema should assume a standard model for defining keywords and stick to it. Why would json-schema want to define a URL keyword for validation?

There is one variation of this that I like which is "this keyword is the same as that keyword"—so if a user keyword or vendor keyword gets standardized with a different name...

I think every schema author has the right to decide if wants to skip a json-schema validation keyword, or to ignore a possible conflict. Also, if I write a css file I can define a wrong rule and it won't affect the correct display for the remaining correct rules. Allowing schema authors to ignore anything they want would also save you from a lot of hassle. E.g., the following would transform format keyword into simple annotation.

{
    "$ignored": ["format"],
    "format": "whatever"
}