Skip to content

Conversation

unsetbit
Copy link
Contributor

@unsetbit unsetbit commented Jul 6, 2014

Fixes various grammar and phrasing issues in the spec. Also fixes a seeming typo in the restriction of discriminator property value of models to be the names of the parent model or any of its sub-models. The intent seems to restrict the discriminator property value of models to NOT be the name of the parent model or any of its sub-models. (Let me know if that wasn't the intent and I can revert that change).

@@ -949,7 +949,7 @@ Field Name | Type | Description
<a name="modelRequired"/>required | [`string`] | A definition of which properties MUST exist when a model instance is produced. The values MUST be the [`{Property Name}`](#propertiesPropertyName) of one of the [`properties`](#528-properties-object).
<a name="modelProperties"/>properties | [Properties Object](#528-properties-object) | **Required.** A list of properties (fields) that are part of the model
<a name="modelSubTypes"/>subTypes | [`string`] | List of the [model `id`s](#modelId) that inherit from this model. Sub models inherit all the properties of the parent model. Since inheritance is transitive, if the parent of a model inherits from another model, its sub-model will include all properties. As such, if you have `Foo->Bar->Baz`, then Baz will inherit the properties of Bar and Foo. There MUST NOT be a cyclic definition of inheritance. For example, if `Foo -> ... -> Bar`, having `Bar -> ... -> Foo` is not allowed. There also MUST NOT be a case of multiple inheritance. For example, `Foo -> Baz <- Bar` is not allowed. A sub-model definition MUST NOT override the [`properties`](#modelProperties) of any of its ancestors. All sub-models MUST be defined in the same [API Declaration](#52-api-declaration).
<a name="modelDiscriminator"/>discriminator | `string` | MUST be included only if [`subTypes`](#modelSubTypes) is included. This field allows for polymorphism within the described inherited models. This field MAY be included at any base model but MUST NOT be included in a sub-model. The value of this field MUST be a name of one of the [`properties`](#modelProperties) in this model, and that field MUST be in the [`required`](#modelRequired) list. When used, the value of the *discriminator property* MUST be the name of parent or any of its sub-models (to any depth of inheritance).
<a name="modelDiscriminator"/>discriminator | `string` | MUST be included only if [`subTypes`](#modelSubTypes) is included. This field allows for polymorphism within the described inherited models. This field MAY be included at any base model but MUST NOT be included in a sub-model. The value of this field MUST be a name of one of the [`properties`](#modelProperties) in this model, and that field MUST be in the [`required`](#modelRequired) list. When used, the value of the *discriminator property* MUST NOT be the name of the parent model or any of its sub-models (to any depth of inheritance).
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please verify that the change to the last sentence is the actual intent of the spec, since it changes a MUST to a MUST NOT (effectively changing the spec).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The original statement is correct. That's what the discriminator is used for.
Say you have these models (simplified sample):
Pet (discriminator:type) { type, name, age }
Cat extends Pet { hasClaws }
Dog extends Pet { likesCats }

In that case, the 'type' field has to be either Pet, Cat or Dog (the model IDs) to indicate which model it is. It can't be any value as that won't be able to be parsed by the consumer/producer.

@webron
Copy link
Member

webron commented Jul 6, 2014

Thank you for this work! I'm really glad you took the time to go over it and make these modifications.
I'll wait for you to amend the change to the description of the discriminator field and then I'll merge it.

@unsetbit
Copy link
Contributor Author

unsetbit commented Jul 6, 2014

Ah, that makes sense, thanks for clarifying, fixed and pushed the amend.

webron added a commit that referenced this pull request Jul 6, 2014
Grammar and phrasing fixes
@webron webron merged commit 3447104 into OAI:master Jul 6, 2014
fehguy added a commit that referenced this pull request Sep 8, 2014
fehguy added a commit that referenced this pull request Sep 8, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants