Update the specs for re-relaying

website/package.json

@@ -12,7 +12,8 @@
     "publish-gh-pages": "docusaurus-publish",
     "write-translations": "docusaurus-write-translations",
     "crowdin-upload": "crowdin-cli --config ../crowdin.yaml upload sources --auto-update -b master",
-    "crowdin-download": "crowdin-cli --config ../crowdin.yaml download -b master"
+    "crowdin-download": "crowdin-cli --config ../crowdin.yaml download -b master",
+    "update-specs":"spec-md spec/Connections.md > static/graphql/connections.htm; spec-md spec/Mutations.md > static/graphql/mutations.htm; spec-md spec/ObjectIdentification.md > static/graphql/objectidentification.htm"
   },
   "dependencies": {
     "docusaurus": "1.6.2",

website/spec/Connections.md

@@ -1,9 +1,14 @@
-Relay Cursor Connections Specification
+GraphQL Cursor Connections Specification
 --------------------------------------
 
-Relay's support for pagination relies on the GraphQL server exposing
-connections in a standardized way. In the query, the connection model
-provides a standard mechanism for slicing and paginating the result set.
+This specification aims to provide options for GraphQL clients to consistently 
+handle pagination with support for related metadata via a GraphQL server. This
+spec proposes calling them connections and treats pageable list in a standardized 
+way. 
+
+In the query, the connection model provides a standard mechanism for slicing 
+and paginating the result set.
+
 In the response, the connection model provides a standard way of providing
 cursors, and a way of telling the client when more results are available.
 
@@ -47,16 +52,16 @@ This section of the spec describes the formal requirements around connections.
 
 # Reserved Types
 
-A GraphQL Relay server must reserve certain types and type names
-to support the pagination model used by Relay. In particular, this spec creates
+A GraphQL server which conforms to this spec must reserve certain types and type names
+to support the pagination model of connections. In particular, this spec creates
 guidelines for the following types:
 
  - Any object whose name ends in "Connection".
  - An object named `PageInfo`.
 
 # Connection Types
 
-Any type whose name ends in "Connection" is considered by Relay
+Any type whose name ends in "Connection" is considered by this spec
 to be a *Connection Type*. Connection types must be an "Object"
 as defined in the "Type System" section of the GraphQL Specification.
 
@@ -143,7 +148,7 @@ returns
 # Edge Types
 
 A type that is returned in list form by a connection type's `edges` field
-is considered by Relay to be an *Edge Type*. Edge types must be an "Object"
+is considered by this spec to be an *Edge Type*. Edge types must be an "Object"
 as defined in the "Type System" section of the GraphQL Specification.
 
 ## Fields
@@ -173,7 +178,7 @@ Non-Null wrapper around a custom scalar that serializes as a String.
 Whatever type this field returns will be referred to as the *cursor type*
 in the rest of this spec.
 
-The result of this field is considered opaque by Relay, but will be passed
+The result of this field is considered opaque by the spec, but will be passed
 back to the server as described in the "Arguments" section below.
 
 ## Introspection

website/spec/Mutations.md

@@ -1,9 +1,9 @@
-Relay Input Object Mutations Specification
+Relay Classic Input Object Mutations Specification
 ------------------------------------------
 
-Relay's support for mutations relies on the GraphQL server exposing
+Relay Classic's support for mutations relies on the GraphQL server exposing
 mutation fields in a standardized way. These mutations accept and emit a
-identifier string, which allows Relay to track mutations and responses.
+identifier string, which allows Relay Classic to track mutations and responses.
 
 All mutations may include in their input a `clientMutationId` string, which is
 then returned as part of the object returned by the mutation field.

website/spec/ObjectIdentification.md

@@ -1,10 +1,11 @@
-Relay Global Object Identification Specification
+GraphQL Global Object Identification Specification
 ------------------------------------------------
 
-Relay's support for object identification relies on the GraphQL server exposing
-object identifiers in a standardized way. In the query, the schema should
-provide a standard mechanism for asking for an object by ID. In the response,
-the schema provides a standard way of providing these IDs.
+To provide options for GraphQL clients to elegantly handle for caching and data 
+refetching GraphQL servers need to expose object identifiers in a standardized 
+way. In the query, the schema should provide a standard mechanism for asking 
+for an object by ID. In the response, the schema provides a standard way of 
+providing these IDs.
 
 We refer to objects with identifiers as "nodes".
 
@@ -28,9 +29,9 @@ refetching.
 
 # Reserved Types
 
-A GraphQL Relay server must reserve certain types and type names
-to support the object identification model used by Relay. In particular, this
-spec creates guidelines for the following types:
+A GraphQL server compatible with this spec must reserve certain types and type names
+to support the consistent object identification model. In particular, this spec creates 
+guidelines for the following types:
 
  - An interface named `Node`.
  - The `node` field on the root query type.
@@ -294,15 +295,15 @@ might return:
 }
 ```
 
-For Relay to be able to link the usernames to the responses, it needs to
+For clients to be able to link the usernames to the responses, it needs to
 know that the array in the response will be the same size as the array
 passed as an argument, and that the order in the response will match the
 order in the argument. We call these *plural identifying root fields*, and
 their requirements are described below.
 
 ## Fields
 
-A Relay-compliant server may expose root fields that accept a list of input
+A server compliant with this spec may expose root fields that accept a list of input
 arguments, and returns a list of responses. For Relay to use these fields,
 these fields must be *plural identifying root fields*, and obey the following
 requirements.