An extension may introduce it's own top-level member. E.g. the atomic operations extension defines the additional top-level members atomic:operations and atomic:results.

So far the specification enforced that a JSON:API document has either data, errors or meta top-level member. Even if there is another top-level member introduced by an applied extension.

This is not desirable. And it was not intended. It is likely that some implementations would ignore that requirement. Even the examples given in official atomic operations extension are ignoring it:

POST /operations HTTP/1.1
Host: example.org
Content-Type: application/vnd.api+json;ext="https://jsonapi.org/ext/atomic"
Accept: application/vnd.api+json;ext="https://jsonapi.org/ext/atomic"

{
  "atomic:operations": [{
    "op": "add",
    "href": "/blogPosts",
    "data": {
      "type": "articles",
      "attributes": {
        "title": "JSON API paints my bikeshed!"
      }
    }
  }]
}

A meta top-level member with an empty object could be added to fulfill that requirement. The example payload from atomic operations extensions would be changed like the following:

  POST /operations HTTP/1.1
  Host: example.org
  Content-Type: application/vnd.api+json;ext="https://jsonapi.org/ext/atomic"
  Accept: application/vnd.api+json;ext="https://jsonapi.org/ext/atomic"

  {
    "atomic:operations": [{
      "op": "add",
      "href": "/blogPosts",
      "data": {
        "type": "articles",
        "attributes": {
          "title": "JSON API paints my bikeshed!"
        }
      }
-   }]
+   }],
+   "meta": {}
  }

But there doesn't seem to be any value in doing so. Instead we should relax the constraint of the base spec to better support this use case of extensions.

I see two potential options to address the issue:

1. We could relax the base spec to not enforce any top-level member. To do so, we would replace MUST with MAY in the sentence.

   - A document **MUST** contain at least one of the following top-level members:
   + A document **MAY** contain at least one of the following top-level members:

2. We could keep the requirement but add top-level members defined by an applied extension as a forth option.

     A document **MUST** contain at least one of the following top-level members:
   
     * `data`: the document's "primary data".
     * `errors`: an array of [error objects](#errors).
     * `meta`: a [meta object][meta] that contains non-standard meta-information.
   + * a member defined by an applied extension.

I tend toward the second approach:

• A JSON:API document without any top-level member would not have any value. I think we should disallow this case in the base spec.
• Allowing a JSON:API document without data, errors or meta top-level member even if no extension is applied, could be considered a breaking change.
• As extension did not exist in v1.0 changing semantics only in case an extension is applied, is not a breaking change.