-
-
Notifications
You must be signed in to change notification settings - Fork 97
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
Present OpenAPI additionalProperties
field
#1162
Present OpenAPI additionalProperties
field
#1162
Conversation
When looking at the "Authentication Data" type used in e.g. the account deactivation endpoint https://spec.matrix.org/v1.3/client-server-api/#post_matrixclientv3accountdeactivate it was not clear to me that clients and servers should expect additional fields in this structure (the semantics of which are implied by the `type` of the authentication, or that of the previously established `session`.) In the OpenAPI spec, We occasionally mark some ojects as allowing arbitrary additional properties (`additionalProperties: true`, or `additionalProperties: { description: "..."}`). In other places we are more strict and provide a schema that additional properties must satisfy. In this PR we aim to make the first kind of additional properties (non-strict) more visible in the rendered spec.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
generally this seems fine, though there seems to be a bit of confusion around what clients are able to send (which is anything it feels like - servers don't have to listen though)
{{ else if (not $additionalProperties) -}} | ||
{{/* At present we don't have any schema with additionalProperties: false. | ||
But if we ever do, let's support it. */}} | ||
May **not** have additional properties. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Everything is extensible in Matrix unless otherwise noted, so this is a bit misleading.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't follow---what do you find misleading?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The whole sentence :D
Additional properties are always allowed, even if not advertised by the spec. The server just isn't required to do anything with them (unless it's dealing with signatures)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay. Then perhaps this can be changed so that
- we don't do anything if
additionalProperties: true
- we raise a build-time error if
additionalProperties: false
- Rather than "May have additional properties:" in the generated HTML, we write "Notes on additional properties:".
How does that sound?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems reasonable, assuming additionalProperties
can be assigned a boolean (I don't think it can?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See https://swagger.io/specification/#schema-object
The following properties are taken from the JSON Schema definition but their definitions were adjusted to the OpenAPI Specification.
- additionalProperties - Value can be boolean or object. Inline or referenced schema MUST be of a Schema Object and not a standard JSON Schema. Consistent with JSON Schema, additionalProperties defaults to true.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And for completeness: the original JSON schema additionalProperties are defined here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
3398cf0 is an attempt at this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@turt2live, @DMRobertson: I'm not sure I'm following the discussion here. Can I just check that everyone is clear what we're discussing?
The question is around the correct behaviour if we encounter an object schema where additionalProperties
is explictly set to false
(as opposed to leaving it unset, which is equivalent to setting it to true
).
Earlier drafts of JSON Schema give a clear definition of what that means:
If "additionalProperties" is false, validation succeeds only if the instance is an object and all properties on the instance were covered by "properties" and/or "patternProperties".
In other words: this is explicitly about trying to define an object which may not be extended.
I don't entirely object to the decision to emit an error message, if we think it's somehow un-matrixy to try to define an object that isn't allowed any additional properties. I'd just like to be sure that we made that decision with good information.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We actually have that case (exactly one, unless I missed some weirdly formatted), and it's in m.receipt
events: . additionalProperties: false
is used next to patternProperties
to forbid anything that does not follow the pattern. Which is quite valid and smart, in my opinion. There's a big question however on what the homeserver is supposed to do with this boundary. I would treat it as a "MUST ignore" of sorts, whereas omitting additionalProperties
entirely would correspond to "MAY ignore". Does it make sense?
Ignore `true` values for additionalProperties. Error on `false` values.
I think this looks better, but what do I know?
Oh. Looks like I have a merge to resolve. |
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Otherwise, it should be an OpenAPI schema object. Include the description | ||
of that schema object, if it exists. */}} | ||
{{ if (and (ne $additionalProperties nil) (ne $additionalProperties true)) }} | ||
{{ if (and (reflect.IsMap $additionalProperties)) -}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
redundant and
here.
{{ if (and (ne $additionalProperties nil) (ne $additionalProperties true)) }} | ||
{{ if (and (reflect.IsMap $additionalProperties)) -}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we restructure these if
statements to reduce the nesting?
{{ if (or (eq $additionalProperties nil) (eq $additionalProperties true)) }}
{{/* do nothing */}}
{{ else if (reflect.IsMap $additionalProperties) -}}
...
{{ else if (not $additionalProperties) -}}
...
{{ end }}
or something.
{{/* TODO: should we handle the case where additional properties are | ||
permitted, but must follow an explicit schema? */}} | ||
{{ else if (not $additionalProperties) -}} | ||
{{ errorf "Unexpected additionalProperties=false for %s" $title }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's unclear to me that we should be raising an error in this case. Isn't it legitimate to specify that a given object may not have additional properties, even if that is currently unused?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤷 There's some context here: #1162 (comment) ; I don't have any strong opinions here.
@DMRobertson are you still interested in pursuing this? Anything we can do to unblock you? |
It'd be nice to do this at some point, but I don't think I'm going to find the time. Let's close this off for now. |
When looking at the "Authentication Data" type used in e.g. the account
deactivation endpoint
it was not clear to me that clients and servers should expect additional
fields in this structure (the semantics of which are implied by the
type
of the authentication, or that of the previously establishedsession
.)In the OpenAPI spec, We occasionally mark some ojects as allowing
arbitrary additional properties (
additionalProperties: true
, oradditionalProperties: { description: "..."}
). In other places we aremore strict and provide a schema that additional properties must satisfy.
In this PR we aim to make the first kind of additional
properties (non-strict) more visible in the rendered spec.
See https://pr1162--matrix-spec-previews.netlify.app/client-server-api/#post_matrixclientv3accountdeactivate
Preview: https://pr1162--matrix-spec-previews.netlify.app