Summary
This issue raises awareness of speciesist language patterns in the GraphQL specification and proposes that future writing consider more inclusive alternatives. This is not a request to rewrite existing examples wholesale, but rather a suggestion that the specification's style guide and editorial process consider this dimension going forward.
What is speciesist language?
Speciesist language uses animals in ways that reinforce their status as property, objects, or lesser beings. In technical documentation, this often manifests as examples that model animals as owned objects with commands to obey — framing that normalizes dominion over other sentient beings. While seemingly innocuous, the cumulative effect of these patterns across technical specifications, tutorials, and documentation shapes how we think about our relationship with other species.
Findings in the current specification
The Pet/Dog/Cat example schema (Section 5 — Validation)
The entire validation section (the largest section of the spec) uses a Pet/Dog/Cat example schema as its primary illustration. This schema contains approximately 100+ references to these animal types across hundreds of code examples. Key patterns include:
owner: Human — Animals modeled explicitly as property of humans (8 occurrences)doesKnowCommand(dogCommand: DogCommand!) — Animals modeled as beings that exist to obey commandsisHouseTrained(atOtherHomes: Boolean) — Animals modeled through the lens of their obedience/utility to humans (17 occurrences of isHouseTrained)DogCommand enum with values SIT, DOWN, HEEL — Reinforcing the command-obedience framingbarkVolume: Int / meowVolume: Int — Reducing animal communication to a measurable nuisanceinterface Pet / union CatOrDog — The term "pet" itself frames animals as existing for human companionship rather than as beings with their own interests
The schema models a world where animals are property (owner), exist to follow commands (doesKnowCommand), are valued for their obedience (isHouseTrained), and are categorized by their utility to humans (Pet).
Other instances
pets: [Pet] in Section 3 (Type System) as the canonical example of List types- "chicken-or-egg dilemma" in CONTRIBUTING.md (line 29) — an animal-derived idiom
What the spec does well
The specification does not use many of the commonly flagged terms in inclusive language guides (no master/slave, no blacklist/whitelist, etc.). The style guide already emphasizes neutral, descriptive tone. This suggests the project is receptive to thoughtful language considerations.
Proposal
This is not a request to immediately refactor the entire validation section. That would be a massive editorial undertaking given the 100+ references deeply woven through the examples. Instead, this issue proposes:
-
Awareness for new writing: When new examples, sections, or significant editorial changes are written, consider using example schemas that don't model animals as property. Alternatives could include books/authors, products/categories, vehicles/manufacturers, projects/contributors, or any other domain that doesn't reinforce hierarchies over sentient beings.
-
Style guide consideration: The existing STYLE_GUIDE.md covers tone, formatting, and conventions well. A brief note about considering inclusive example domains (not just inclusive pronouns/terms, but inclusive framing) when writing new content could be valuable.
-
Gradual evolution: If major editorial work is ever undertaken on the validation section examples, consider this dimension as part of that work.
Context
The tech industry has increasingly recognized that language in specifications and documentation matters — efforts around master/slave terminology, gendered language, and other inclusive language initiatives have been widely adopted. Speciesist language is a natural extension of this same principle: that our default examples and metaphors shape assumptions about who and what matters.
Other specifications and style guides that have considered inclusive language:
These precedents focused on racial and gendered language, but the underlying principle — that normative technical documents should not casually reinforce hierarchies over any group of sentient beings — applies equally here.
What this is not
- This is not a request for immediate, sweeping changes
- This is not a criticism of the spec authors' intentions
- This is not asking GraphQL to take a political position on animal rights
It is simply a request to consider, as a matter of editorial awareness going forward, whether examples that model animals as obedient property are the best choice when neutral alternatives exist.
Summary
This issue raises awareness of speciesist language patterns in the GraphQL specification and proposes that future writing consider more inclusive alternatives. This is not a request to rewrite existing examples wholesale, but rather a suggestion that the specification's style guide and editorial process consider this dimension going forward.
What is speciesist language?
Speciesist language uses animals in ways that reinforce their status as property, objects, or lesser beings. In technical documentation, this often manifests as examples that model animals as owned objects with commands to obey — framing that normalizes dominion over other sentient beings. While seemingly innocuous, the cumulative effect of these patterns across technical specifications, tutorials, and documentation shapes how we think about our relationship with other species.
Findings in the current specification
The Pet/Dog/Cat example schema (Section 5 — Validation)
The entire validation section (the largest section of the spec) uses a
Pet/Dog/Catexample schema as its primary illustration. This schema contains approximately 100+ references to these animal types across hundreds of code examples. Key patterns include:owner: Human— Animals modeled explicitly as property of humans (8 occurrences)doesKnowCommand(dogCommand: DogCommand!)— Animals modeled as beings that exist to obey commandsisHouseTrained(atOtherHomes: Boolean)— Animals modeled through the lens of their obedience/utility to humans (17 occurrences ofisHouseTrained)DogCommandenum with valuesSIT,DOWN,HEEL— Reinforcing the command-obedience framingbarkVolume: Int/meowVolume: Int— Reducing animal communication to a measurable nuisanceinterface Pet/union CatOrDog— The term "pet" itself frames animals as existing for human companionship rather than as beings with their own interestsThe schema models a world where animals are property (
owner), exist to follow commands (doesKnowCommand), are valued for their obedience (isHouseTrained), and are categorized by their utility to humans (Pet).Other instances
pets: [Pet]in Section 3 (Type System) as the canonical example of List typesWhat the spec does well
The specification does not use many of the commonly flagged terms in inclusive language guides (no master/slave, no blacklist/whitelist, etc.). The style guide already emphasizes neutral, descriptive tone. This suggests the project is receptive to thoughtful language considerations.
Proposal
This is not a request to immediately refactor the entire validation section. That would be a massive editorial undertaking given the 100+ references deeply woven through the examples. Instead, this issue proposes:
Awareness for new writing: When new examples, sections, or significant editorial changes are written, consider using example schemas that don't model animals as property. Alternatives could include books/authors, products/categories, vehicles/manufacturers, projects/contributors, or any other domain that doesn't reinforce hierarchies over sentient beings.
Style guide consideration: The existing STYLE_GUIDE.md covers tone, formatting, and conventions well. A brief note about considering inclusive example domains (not just inclusive pronouns/terms, but inclusive framing) when writing new content could be valuable.
Gradual evolution: If major editorial work is ever undertaken on the validation section examples, consider this dimension as part of that work.
Context
The tech industry has increasingly recognized that language in specifications and documentation matters — efforts around master/slave terminology, gendered language, and other inclusive language initiatives have been widely adopted. Speciesist language is a natural extension of this same principle: that our default examples and metaphors shape assumptions about who and what matters.
Other specifications and style guides that have considered inclusive language:
These precedents focused on racial and gendered language, but the underlying principle — that normative technical documents should not casually reinforce hierarchies over any group of sentient beings — applies equally here.
What this is not
It is simply a request to consider, as a matter of editorial awareness going forward, whether examples that model animals as obedient property are the best choice when neutral alternatives exist.