├── .github ├── ISSUE_TEMPLATE.md ├── PULL_REQUEST_TEMPLATE.md └── workflows │ └── ci.yml ├── scalars ├── input-coercion.png ├── template-string.md ├── template.md ├── contributed │ └── andimarek │ │ ├── local-date.md │ │ └── date-time.md └── implementation-guide.md ├── .gitignore ├── .prettierignore ├── package.json └── README.md /.github/ISSUE_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /scalars/input-coercion.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/graphql/graphql-scalars/HEAD/scalars/input-coercion.png -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | *.swp 2 | *~ 3 | .*.haste_cache.* 4 | .DS_Store 5 | npm-debug.log 6 | /build 7 | /public 8 | /gh-pages 9 | /node_modules 10 | .idea 11 | -------------------------------------------------------------------------------- /.prettierignore: -------------------------------------------------------------------------------- 1 | *.swp 2 | *~ 3 | .*.haste_cache.* 4 | .DS_Store 5 | npm-debug.log 6 | /build 7 | /changelogs 8 | /out 9 | /gh-pages 10 | /node_modules 11 | /package.json 12 | -------------------------------------------------------------------------------- /.github/PULL_REQUEST_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | !!! IMPORTANT !!! 2 | 3 | Please Read 4 | https://github.com/graphql/graphql-scalars/blob/master/CONTRIBUTING.md before 5 | creating a Pull Request. 6 | -------------------------------------------------------------------------------- /package.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "graphql-scalars", 3 | "private": true, 4 | "license": "OWFa-1.0", 5 | "homepage": "https://scalars.graphql.org/", 6 | "repository": { 7 | "type": "git", 8 | "url": "http://github.com/graphql/graphql-scalars.git" 9 | }, 10 | "scripts": { 11 | "test": "npm run test:spelling && npm run test:format && npm run test:build", 12 | "test:spelling": "cspell \"**/*.md\"", 13 | "test:format": "prettier --check \"**/*.{md,yml,yaml,json}\"", 14 | "format": "prettier --write \"**/*.{md,yml,yaml,json}\"", 15 | "test:build": "OUT_DIR=$(mktemp -d) ./build.sh", 16 | "build": "OUT_DIR=public ./build.sh", 17 | "watch": "nodemon -e json,md --exec \"npm run build\"" 18 | }, 19 | "devDependencies": { 20 | "cspell": "6.18.1", 21 | "nodemon": "2.0.20", 22 | "prettier": "2.8.2", 23 | "spec-md": "3.1.0" 24 | }, 25 | "prettier": { 26 | "proseWrap": "always", 27 | "trailingComma": "none" 28 | } 29 | } 30 | -------------------------------------------------------------------------------- /scalars/template-string.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | # \ — GraphQL Custom Scalar 4 | 5 | "Author - \ " 6 | 7 | "Date - \" 8 | 9 | This template is meant to be copied and modified. This template is meant for 10 | Scalars which are based on the built-in String Scalar 11 | 12 | **License and Copyright** 13 | 14 | Copyright © GraphQL contributors. This specification is licensed under 15 | [OWFa 1.0](https://www.openwebfoundation.org/the-agreements/the-owf-1-0-agreements-granted-claims/owfa-1-0). 16 | 17 | # Overview 18 | 19 | Provide an overview of what this Scalar does and provide any background 20 | information. 21 | 22 | # Recommended name 23 | 24 | Provide a recommended Scalar name and list alternatives, if available. 25 | 26 | # Result spec 27 | 28 | Define which Strings can be returned. 29 | 30 | Provide positive and negative examples of String return values. 31 | 32 | # Input spec 33 | 34 | Define which String values are accepted as input as GraphQL Literal and as JSON 35 | raw input. 36 | 37 | Provide positive and negative examples of literal and JSON raw input values. 38 | 39 | # References 40 | 41 | List external references, other background information etc. 42 | -------------------------------------------------------------------------------- /.github/workflows/ci.yml: -------------------------------------------------------------------------------- 1 | name: CI 2 | 3 | on: 4 | push: 5 | branches: 6 | - main 7 | pull_request: 8 | 9 | jobs: 10 | test-spelling: 11 | runs-on: ubuntu-latest 12 | steps: 13 | - uses: actions/checkout@v3 14 | - uses: actions/setup-node@v3 15 | - run: npm ci 16 | - run: npm run test:spelling 17 | test-format: 18 | runs-on: ubuntu-latest 19 | steps: 20 | - uses: actions/checkout@v3 21 | - uses: actions/setup-node@v3 22 | - run: npm ci 23 | - run: npm run test:format 24 | test-build: 25 | runs-on: ubuntu-latest 26 | steps: 27 | - uses: actions/checkout@v3 28 | - uses: actions/setup-node@v3 29 | - run: npm ci 30 | - run: npm run test:build 31 | publish: 32 | if: github.ref == 'refs/heads/main' 33 | needs: 34 | - test-format 35 | - test-spelling 36 | - test-build 37 | runs-on: ubuntu-latest 38 | steps: 39 | - uses: actions/checkout@v3 40 | - uses: actions/setup-node@v3 41 | - run: npm ci 42 | - run: npm run build 43 | - uses: peaceiris/actions-gh-pages@v3 44 | with: 45 | github_token: ${{ secrets.GITHUB_TOKEN }} 46 | cname: scalars.graphql.org 47 | user_name: "github-actions[bot]" 48 | user_email: "github-actions[bot]@users.noreply.github.com" 49 | -------------------------------------------------------------------------------- /scalars/template.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | # \ — GraphQL Custom Scalar 4 | 5 | "Author - \ " 6 | 7 | "Date - \" 8 | 9 | This template is meant to be copied and modified. This template is meant for 10 | Scalars which are _not_ based on the built-in String Scalar 11 | 12 | **License and Copyright** 13 | 14 | Copyright © GraphQL contributors. This specification is licensed under 15 | [OWFa 1.0](https://www.openwebfoundation.org/the-agreements/the-owf-1-0-agreements-granted-claims/owfa-1-0). 16 | 17 | # Overview 18 | 19 | Provide an overview of what this Scalar does and provide any background 20 | information. 21 | 22 | # Recommended name 23 | 24 | Provide a recommended Scalar name and list alternatives, if available. 25 | 26 | # Result JSON spec 27 | 28 | Define which JSON values can be returned. 29 | 30 | Provide positive and negative examples of JSON values. 31 | 32 | # Literal Input spec 33 | 34 | Define which GraphQL Literals are accepted as input. 35 | 36 | Provide positive and negative examples of literals. 37 | 38 | # Raw Input JSON spec 39 | 40 | Define which JSON values are accepted as input. 41 | 42 | Provide positive and negative examples of JSON values. 43 | 44 | # References 45 | 46 | List external references, other background information etc. 47 | -------------------------------------------------------------------------------- /scalars/contributed/andimarek/local-date.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | # LocalDate — GraphQL Custom Scalar 4 | 5 | "Author - andimarek" 6 | 7 | "Date - 2023-01-18" 8 | 9 | This is a String-based scalar. 10 | 11 | **License and Copyright** 12 | 13 | Copyright © GraphQL contributors. This specification is licensed under 14 | [OWFa 1.0](https://www.openwebfoundation.org/the-agreements/the-owf-1-0-agreements-granted-claims/owfa-1-0). 15 | 16 | # Overview 17 | 18 | This scalar represents a date without a time-zone in the 19 | [ISO-8601](https://en.wikipedia.org/wiki/ISO_8601) calendar system. 20 | 21 | The pattern is "YYYY-MM-DD" with "YYYY" representing the year, "MM" the month, 22 | and "DD" the day. 23 | 24 | Valid examples are "1983-10-20" or "2023-04-01". An invalid example would be 25 | "2011-13-10" because there isn't a 13th month in a year. 26 | 27 | The prefix "Local" comes from the fact that without a time-zone it is not a 28 | specific point in time, but rather expresses a "local point of view". A popular 29 | use case for using this scalar are birthdays for example, which are normally not 30 | stored with a specific time zone. 31 | 32 | Because this scalar depends on the ISO-8601 calendar it is not recommended to 33 | use for dates before the year 1582. 34 | 35 | # Name 36 | 37 | The recommended name is "LocalDate". 38 | 39 | # Result 40 | 41 | Every result must follow the pattern "YYYY-MM-DD" as described above. 42 | 43 | # Input 44 | 45 | Every input must follow the pattern "YYYY-MM-DD" as described above. 46 | 47 | # References 48 | 49 | [ISO-8601](https://en.wikipedia.org/wiki/ISO_8601) 50 | -------------------------------------------------------------------------------- /scalars/contributed/andimarek/date-time.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | # DateTime — GraphQL Custom Scalar 4 | 5 | Author - andimarek 6 | 7 | Date - 2022-10-18 8 | 9 | This is a String-based scalar. 10 | 11 | **License and Copyright** 12 | 13 | Copyright © GraphQL contributors. This specification is licensed under 14 | [OWFa 1.0](https://www.openwebfoundation.org/the-agreements/the-owf-1-0-agreements-granted-claims/owfa-1-0). 15 | 16 | # Overview 17 | 18 | This scalar represents an exact point in time. This point in time is specified 19 | by having an offset to UTC and does **not** use a time zone. 20 | 21 | It is a slightly refined version of 22 | [RFC 3339](https://tools.ietf.org/html/rfc3339), including the 23 | [errata](https://www.rfc-editor.org/errata/rfc3339). 24 | 25 | All definitions of RFC 3339 are adopted and nothing is added or removed unless 26 | explicitly mentioned here. 27 | 28 | The following refinements/clarifications apply: 29 | 30 | **Only "date-time"** 31 | 32 | This scalar represents a “date-time” as specified in section 5.6 of RFC 3339. 33 | 34 | The other productions in section 5.6 are only used to support "date-time" but 35 | never stand alone for this scalar. 36 | 37 | **Non-optional exact milliseconds** 38 | 39 | RFC 3339 defines `time-secfrac` optional as: 40 | 41 | ``` 42 | time-secfrac = "." 1*DIGIT (Meaning 1 or more DIGIT) 43 | ``` 44 | 45 | This allows for an unlimited number of digits. For this scalar, the rule is no 46 | longer optional and is refined as: 47 | 48 | ``` 49 | time-secfrac = "." DIGIT DIGIT DIGIT 50 | ``` 51 | 52 | ... consisting always of exactly three digits representing milliseconds. 53 | 54 | **No 'Unknown Local Offset Convention'** 55 | 56 | [Section 4.3](https://tools.ietf.org/html/rfc3339#section-4.3) says: 57 | 58 | ``` 59 | If the time in UTC is known, but the offset to local time is unknown, 60 | this can be represented with an offset of "-00:00". 61 | ``` 62 | 63 | In order to simplify this scalar this convention is dropped and an offset of 64 | `-00:00` is not allowed. 65 | 66 | **Examples** 67 | 68 | The general format is described in 69 | [RFC3339 Section 5.6](https://www.rfc-editor.org/rfc/rfc3339#section-5.6). 70 | 71 | Under consideration of the additional restrictions and explanations above here 72 | are valid and invalid examples: 73 | 74 | These are valid examples: 75 | 76 | | String | Explanation | 77 | | ------------------------------- | -------------------------------------------------- | 78 | | `2011-08-30T13:22:53.108Z` | A DateTime with UTC offset (+00:00). | 79 | | `2011-08-30T13:22:53.108+00:00` | A DateTime with `+00:00` which is the same as UTC. | 80 | | `2011-08-30t13:22:53.108z` | The `z` and `t` may be lower case. | 81 | | `2011-08-30T13:22:53.108-03:00` | A DateTime with -3h offset. | 82 | | `2011-08-30T13:22:53.108+03:30` | A DateTime with +3h 30min offset. | 83 | 84 | These are invalid examples: 85 | 86 | | String | Why is it invalid | 87 | | ---------------------------------- | ------------------------------------------------------------------ | 88 | | `2011-08-30T13:22:53.108-03` | The minutes of the offset are missing. | 89 | | `2011-08-30T13:22:53.108912Z` | Too many digits for fractions of a second. Exactly three expected. | 90 | | `2011-08-30T23:22:53Z` | Fractions of a second are missing. | 91 | | `2011-08-30T13:22:53.108` | No offset provided. | 92 | | `2011-08-30` | No time provided. | 93 | | `2011-08-30T13:22:53.108-00:00` | Negative offset (`-00:00`) is not allowed | 94 | | `2011-08-30T13:22:53.108+03:30:15` | Seconds are not allowed for the offset | 95 | | `2011-08-30T24:22:53.108Z` | `24` is not allowed as hour of the time. | 96 | | `2010-02-30T21:22:53.108Z` | 30th of February is not a valid date | 97 | | `2010-02-11T21:22:53.108+25:11` | 25 is not a valid hour for offset | 98 | 99 | # Name 100 | 101 | The recommended name is `DateTime`. An alternative is `OffsetDateTime`. 102 | 103 | `Date` is potentially misleading as this scalar also specifies a time, not only 104 | a date. 105 | 106 | # Result 107 | 108 | The result must be formatted as described above with the further requirement 109 | that UTC offset should be always be represented as `Z` and not `+00:00` and the 110 | two divider characters `T` and `Z` are always uppercase, never `t` or `z`. 111 | 112 | # Input 113 | 114 | As input, every valid String as described above must be accepted. 115 | -------------------------------------------------------------------------------- /scalars/implementation-guide.md: -------------------------------------------------------------------------------- 1 | # GraphQL Scalars implementation guide 2 | 3 | [Scalar types](https://spec.graphql.org/draft/#sec-Scalars) are primitive types 4 | in the GraphQL type system, usable for input and output. 5 | 6 | ## Serialization and Deserialization 7 | 8 | A GraphQL request often requires a deserialization step before being executed 9 | and a serialization of the execution result. By far the most frequently used 10 | example is a GraphQL request sent over HTTP POST via JSON. The request body is a 11 | JSON document that needs to be deserialized, containing the GraphQL document and 12 | optionally an operation name and variables. 13 | 14 | The execution result then is serialized to JSON for the HTTP response. As JSON 15 | serialization is the most common GraphQL serialization format, the spec defines 16 | how a GraphQL result should be 17 | [serialized to JSON](https://spec.graphql.org/draft/#sec-JSON-Serialization). 18 | 19 | For the discussion of Scalars, the deserialization of the variables is 20 | significant. Deserialized variable values are one of the possible inputs a 21 | Scalar implementation needs to handle. 22 | 23 | ## Observability 24 | 25 | A Scalar implementation can be observed in three different ways: 26 | 27 | 1. the serialized result of an execution in JSON 28 | 2. the variables JSON input 29 | 3. the GraphQL literal input 30 | 31 | We must choose a serialization format in order to observe a Scalar 32 | implementation, as inside the GraphQL type system a Scalar is a primitive and 33 | how a Scalar is represented in an execution result before serialization is 34 | entirely up to the specific engine. 35 | 36 | We are choosing to only consider JSON. Although JSON is only one possible 37 | serialization format, it is by far the most important and the only format 38 | defined by the GraphQL spec. 39 | 40 | ## Coercion 41 | 42 | The process of ensuring that a value is valid and optionally converting it into 43 | a more appropriate representation is called "coercion". For Scalars, there are 44 | two different coercion mechanisms: "Result Coercion" and "Input Coercion". Both 45 | are implemented as a set of functions taking an input and producing an output. 46 | Result coercion consists of one function and input coercion of up to three 47 | different ones. 48 | 49 | Note: The input of a function is not to be confused with "Input Coercion". The 50 | phrase "Input Coercion" refers to the overall mechanism, but the word "input" 51 | describes what is consumed by a function. 52 | 53 | ## Result Coercion values and function 54 | 55 | Result coercion is implemented as a single function per Scalar type called 56 | `coerceResult`. The input is a "raw result value" and the output a "coerced 57 | result value". The raw result value is the output of a previously invoked 58 | resolver function, which is then coerced by invoking `coerceResult`. 59 | 60 | The coerced result value is a leaf value of the overall execution result, which 61 | is serialized to JSON. The serialized JSON value can be observed and a GraphQL 62 | Scalar spec must clearly define the possible JSON values that a Scalar type can 63 | produce. 64 | 65 | ## Input Coercion values 66 | 67 | Input coercion deals with three different kind of values: literal, raw input 68 | value and coerced input value. 69 | 70 | ### Literal 71 | 72 | A literal is an element of the GraphQL language representing a fixed value. For 73 | example, `"foo"` is a `StringValue` literal and `123` is an `IntValue` literal. 74 | 75 | Literals are used for: 76 | 77 | 1. argument values for fields or directives 78 | 79 | 2. argument default values for fields or directives 80 | 81 | 3. variable default values of a GraphQL operation 82 | 83 | ### Raw Input Value 84 | 85 | A raw input value is one of the following: 86 | 87 | 1. variable value for a GraphQL request 88 | 89 | 2. programmatically provided default argument value for a field or directive 90 | 91 | 3. programmatically provided default value for an input object field 92 | 93 | 4. programmatically provided value for a directive argument in schema definition 94 | language (SDL) 95 | 96 | Not every GraphQL implementation may offer a programmatic way to provide these 97 | input values, but every implementation needs to allow for raw input values 98 | offered as variable values for a request. 99 | 100 | The details of a raw input value is implementation specific. In JavaScript, it 101 | might a Map, in Java it might be an object. The only way to observe a raw input 102 | value is through the JSON value before deserialization. 103 | 104 | ### Coerced Input Value 105 | 106 | A coerced input value is a value that is ready for consumption by a resolver. It 107 | is coerced either from a literal or raw input value. 108 | 109 | ## Input coercion functions 110 | 111 | Input coercion is implemented as a set of three functions `parseLiteral`, 112 | `parseRawInputValue` and `rawInputValueToLiteral`. 113 | 114 | The diagram illustrates the relationships between input coercion values. 115 | 116 | ![Input Coercion](input-coercion.png) 117 | 118 | ### Parse Literal 119 | 120 | `parseLiteral` takes a GraphQL language literal as input and produces a coerced 121 | input value as output. 122 | 123 | ### Parse Raw Input Value 124 | 125 | `parseRawInputValue` takes a "raw input value" as input and produces a "coerced 126 | input value". 127 | 128 | ### Raw Input Value to Literal 129 | 130 | `rawInputValueToLiteral` takes a raw input value as input and produces a GraphQL 131 | language literal. 132 | 133 | It is used when a literal representation of a raw input value is required. For 134 | example the default value for a field in an Introspection response. If a GraphQL 135 | implementation doesn't provide a way to define a raw input value 136 | programmatically, `rawInputValueToLiteral` might not be needed. 137 | 138 | ### Implementation rules 139 | 140 | These three functions need to be compatible to each other, specifically: 141 | 142 | **Rule 1:** every valid input for `parseRawInputValue` must be a valid input for 143 | `rawInputValueToLiteral` and vice versa. This rule ensures that every raw input 144 | value can be represented as literal. 145 | 146 | **Rule 2:** for every valid input for `parseLiteral` there must at least one 147 | corresponding input for `parseRawInputValue` resulting in the same coerced input 148 | value. This rule ensures that all literals can be represented as raw input 149 | value. 150 | 151 | **Rule 3:** every output for `rawInputValueToLiteral` must be a valid input for 152 | `parseLiteral`. 153 | 154 | These rules ensure that for every valid literal we have at least one valid raw 155 | value and vice versa. 156 | 157 | ## Coercion guidelines 158 | 159 | While the specifics of the all coercion methods are implementation specific, as 160 | a general rule they should only coerce a value when no information is lost and 161 | raise an error otherwise. 162 | 163 | Additionally, the input coercion should be liberal in what it accepts, while the 164 | result coercion should be much more restricted and never produce different JSON 165 | values for logically identical values. For example a `MyLocalDate` scalar could 166 | accept the literals `"01-10-2022"` and `"01102022"` as input for the first of 167 | October 2022, but the result coercion should always return one of the possible 168 | representations. 169 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # GraphQL Custom Scalars Specification Contribution Guide 2 | 3 | Thanks for contributing to GraphQL Scalars. 4 | 5 | The goal of the GraphQL Scalars project is to provide a directory of GraphQL 6 | Custom Scalar specifications, contributed by the community. Contributed 7 | specifications are hosted on a GraphQL Foundation owned domain 8 | [scalars.graphql.org](https://scalars.graphql.org), which can be referenced with 9 | the built-in `@specifiedBy` 10 | [GraphQL directive](https://spec.graphql.org/draft/#sec--specifiedBy). 11 | 12 | GraphQL Custom Scalar specifications are language agnostic and thus can be used 13 | to document and standardize behavior across different languages. 14 | 15 | Please ensure that you read the 16 | [Code of Conduct](https://graphql.org/codeofconduct/) before contributing to 17 | this project. 18 | 19 | ## How to contribute 20 | 21 | 1. Copy the `template-string.md` 22 | [template](https://github.com/graphql/graphql-scalars/blob/main/scalars/template-string.md) 23 | for Custom Scalars based on the built-in String Scalar, or otherwise use the 24 | `template.md` 25 | [template](https://github.com/graphql/graphql-scalars/blob/main/scalars/template.md) 26 | for all other Custom Scalars. Templates are located in the 27 | [graphql-scalars GitHub repository](https://github.com/graphql/graphql-scalars/tree/main/scalars). 28 | 29 | 2. Modify your selected template, and save it in the correct place 30 | `scalars/contributed//.md` in 31 | the 32 | [graphql-scalars GitHub repository](https://github.com/graphql/graphql-scalars/tree/main/scalars/contributed). 33 | The directory location is important, as this will form part of the reference 34 | URL for your specification. In case you are using an organization name, we 35 | will manually verify that you are allowed to make the contribution in the 36 | name of the organization. 37 | 38 | 3. Install dependencies with `npm install` and the run `npm run build` to 39 | locally build the resulting public specification files. Navigate to the 40 | `/public` folder to view the built files. 41 | 42 | 4. Run `npm test` to ensure proper formatting before submitting a pull request. 43 | 44 | 5. [Open a new pull request](https://github.com/graphql/graphql-scalars/pulls) 45 | for each Custom Scalar specification you would like to add. 46 | 47 | ### Review process for new specifications 48 | 49 | Because this repository is separate from the main GraphQL spec, and because 50 | several specifications may exist concurrently under different names/authors, the 51 | review process for new specifications under `contributed/` is very light. 52 | 53 | Anyone may review pull requests. Feedback may or may not be incorporated at the 54 | discretion of the original author. When they consider the pull request has 55 | reached a satisfactory state, but not before a 2 week review window, the author 56 | may ask a TSC member to merge the pull request. The TSC will then merge the pull 57 | request without further discussion. 58 | 59 | ### Review process for other parts of this repository 60 | 61 | This document, and all content excluding `contributed/` may be changed with the 62 | [TSC](https://github.com/graphql/graphql-wg/blob/main/GraphQL-TSC.md)'s 63 | approval. This is usually longer than reviewing new specifications. 64 | 65 | ### Immutable specifications 66 | 67 | Specification semantics must not change, as specifications are publicly 68 | available reference documents. We will permit small edits which do not change 69 | specification semantics, such as typo fixes. 70 | 71 | A new version of a Custom Scalar specification must use a new URL but may still 72 | recommend using the old name. 73 | 74 | For example, `scalars/contributed/my_username/date-time-v2.md` may recommend 75 | using `DateTime` for the scalar name. 76 | 77 | You may use a `-v` suffix to indicate new versions, but this is not a 78 | requirement. 79 | 80 | ## Licensing 81 | 82 | Specifications contributed to the GraphQL Scalars repository are part of the 83 | GraphQL Specification Project and are made available by the 84 | [Joint Development Foundation](https://www.jointdevelopment.org/). The current 85 | [GraphQL Working Group](https://github.com/graphql/graphql-wg) charter, which 86 | includes the IP policy governing all working group deliverables (including 87 | specifications, source code, and datasets) may be found in the 88 | [technical charter](https://technical-charter.graphql.org). 89 | 90 | By contributing to this repository, you agree to license your work according to 91 | the licenses governing GraphQL Specification Project deliverables, which are: 92 | 93 | | Deliverable | License | 94 | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | 95 | | Specifications | [Open Web Foundation Agreement 1.0 (Patent and Copyright Grants)](https://www.openwebfoundation.org/the-agreements/the-owf-1-0-agreements-granted-claims/owfa-1-0) | 96 | | Source code | [MIT License](https://opensource.org/licenses/MIT) | 97 | | Data sets | [CC0 1.0](https://creativecommons.org/publicdomain/zero/1.0/) | 98 | 99 | ### Contributor License Agreement 100 | 101 | This repository is managed by EasyCLA. Project participants must sign the free 102 | [GraphQL Specification Membership agreement](https://preview-spec-membership.graphql.org) 103 | before making a contribution. You only need to do this one time, and it can be 104 | signed by 105 | [individual contributors](http://individual-spec-membership.graphql.org/) or 106 | their [employers](http://corporate-spec-membership.graphql.org/). 107 | 108 | To initiate the signature process please open a PR against this repo. The 109 | EasyCLA bot will block the merge if we still need a membership agreement from 110 | you. 111 | 112 | You can find 113 | [detailed information here](https://github.com/graphql/graphql-wg/tree/main/membership). 114 | If you have issues, please email 115 | [operations@graphql.org](mailto:operations@graphql.org). 116 | 117 | ### Copyright 118 | 119 | Copyright © GraphQL contributors 120 | 121 | THESE MATERIALS ARE PROVIDED “AS IS”. The parties expressly disclaim any 122 | warranties (express, implied, or otherwise), including implied warranties of 123 | merchantability, non-infringement, fitness for a particular purpose, or title, 124 | related to the materials. The entire risk as to implementing or otherwise using 125 | the materials is assumed by the implementer and user. IN NO EVENT WILL THE 126 | PARTIES BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, 127 | SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES 128 | OF ACTION OF ANY KIND WITH RESPECT TO THIS DELIVERABLE OR ITS GOVERNING 129 | AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR 130 | OTHERWISE, AND WHETHER OR NOT THE OTHER MEMBER HAS BEEN ADVISED OF THE 131 | POSSIBILITY OF SUCH DAMAGE. 132 | 133 | ## Code of Conduct 134 | 135 | This project abides by the GraphQL Foundation's 136 | [Code of Conduct](https://graphql.org/codeofconduct/). 137 | --------------------------------------------------------------------------------