Skip to content

Conversation

magicmark
Copy link
Contributor

@magicmark magicmark commented Nov 18, 2020

👋

I've pulled out the proposed spec edits for Schema Coordinates (issue: #735) into this PR.

(The RFC now lives in the original PR: https://github.com/graphql/graphql-spec/pull/746/files)

@leebyron you mentioned it might be possible to simplify the grammar - I played around a bit since the original PR, but I think I need some help here. What did you have in mind?

As suggested, tagging @eapache @mjmahone as additional reviewers as we had some good conversation in last WG meeting about this.

Thanks!


GraphQL.js PR: graphql/graphql-js#3044

@magicmark
Copy link
Contributor Author

magicmark commented Nov 18, 2020

Oh also, here's another option I had for the examples table, was thinking it might be good to explicitly show all the different kinds of schema you can select:

Screen Shot 2020-11-17 at 10 38 01 PM

felt slightly too verbose to me, but curious to see if anyone prefers this

Copy link
Member

@benjie benjie left a comment

Choose a reason for hiding this comment

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

Thanks for your hard work on this!

Copy link
Member

@benjie benjie left a comment

Choose a reason for hiding this comment

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

Looks good to me; a few optional tweaks suggested.

Comment on lines 379 to 399
Schema Coordinates are always unique. Each type, field, argument, enum value, or
directive may be referenced by exactly one possible Schema Coordinate.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

feels like something worth highlighting and being clear about as a guarantee in the spec

Comment on lines 382 to 391
For example, the following is *not* a valid Schema Coordinate:

```graphql counter-example
Entity.Business
```

In this counter example, both `Entity.Business` and `Business` would refer to
the `Business` type. Since it would be ambiguous what the "primary key" should
be in an application that uses Schema Coordinates to reference types, this is
not allowed.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

is this waffle? thought it might be helpful to have a little explanation/demonstration of this property

Copy link
Contributor Author

@magicmark magicmark Jan 4, 2021

Choose a reason for hiding this comment

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

Could just be

- Since it would be ambiguous what the "primary key" should be in an application that uses Schema Coordinates to reference types, this is not allowed.
+ Such ambiguity is disallowed (and hence why this is is invalid syntax).

(More terse, but doesn't walk the reader through why this is bad)

Voting lines are now open!

Copy link
Member

Choose a reason for hiding this comment

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

In this counter example, Entity.Business is redundant since Business already uniquely identifies the Business type. Such redundancy is disallowed by this spec - every type, field, field argument, enum value, directive, and directive argument has exactly one canonical Schema Coordinate.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

👍 thanks benjie, stealing this wording

magicmark added a commit to magicmark/graphql-wg that referenced this pull request Jan 4, 2021
Happy new year! 🥳

It's possible we still want more time for the RFC to marinate, but I'll attend so I can be available to folks to discuss the schema coordinates rfc/spec edit in person.

graphql/graphql-spec#794

Thanks!
@leebyron leebyron added the 💡 Proposal (RFC 1) RFC Stage 1 (See CONTRIBUTING.md) label Jan 7, 2021
Base automatically changed from master to main February 3, 2021 04:50
@mcohen75
Copy link

mcohen75 commented Feb 4, 2021

At Indeed we log usage of schema elements to 1) support deprecation and 2) understand usage from a product management perspective (i.e. is this API we built adding value?).

We defined our own coordinate system that is not quite as complete as this spec. A nice benefit of formalizing a coordinate system is that shared tools can be built to solve these and other use cases.

👍 👍 👍

@leebyron leebyron added 📄 Draft (RFC 2) RFC Stage 2 (See CONTRIBUTING.md) and removed 💡 Proposal (RFC 1) RFC Stage 1 (See CONTRIBUTING.md) labels Mar 4, 2021
@leebyron leebyron added this to the May2021 milestone Apr 13, 2021
@leebyron leebyron force-pushed the schema_coordinates_spec_edit branch 3 times, most recently from 4f854af to c0b82d5 Compare April 13, 2021 23:57
@leebyron
Copy link
Collaborator

I made some fairly significant edits to the prose and examples section in an attempt to simplify. @magicmark please take a look and let me know what you think.

@leebyron leebyron force-pushed the schema_coordinates_spec_edit branch 3 times, most recently from 81ef020 to 4299d8c Compare April 14, 2021 01:18
@leebyron leebyron requested review from benjie and a team April 14, 2021 01:20
@leebyron leebyron changed the title Schema Coordinates: add spec edit Schema Coordinates Apr 14, 2021
@leebyron
Copy link
Collaborator

IIRC the only thing holding this from Approval stage is a landed GraphQL.js PR?

@leebyron leebyron added 🏁 Accepted (RFC 3) RFC Stage 3 (See CONTRIBUTING.md) and removed 📄 Draft (RFC 2) RFC Stage 2 (See CONTRIBUTING.md) labels Jul 3, 2025
magicmark and others added 2 commits July 4, 2025 09:14
@benjie
Copy link
Member

benjie commented Jul 4, 2025

@magicmark Here's my original diff that I drafted up locally:

diff --git a/spec/Section 2 -- Language.md b/spec/Section 2 -- Language.md
index e422d9a..7a6dc1f 100644
--- a/spec/Section 2 -- Language.md	
+++ b/spec/Section 2 -- Language.md	
@@ -113,6 +113,8 @@ Comments are {Ignored} like white space and may appear after any token, or
 before a {LineTerminator}, and have no significance to the semantic meaning of a
 GraphQL Document.
 
+Comments are forbidden within a _schema coordinate_.
+
 ### Insignificant Commas
 
 Comma :: ,
@@ -154,25 +156,27 @@ Ignored ::
 - Comma
 
 {Ignored} tokens are used to improve readability and provide separation between
-lexical tokens, but are otherwise insignificant and not referenced in
-syntactical grammar productions.
+lexical tokens in a GraphQL document, but are otherwise insignificant and not
+referenced in syntactical grammar productions. {Ignored} are forbidden within a
+_schema coordinate_.
 
-Any amount of {Ignored} may appear before and after every lexical token. No
-ignored regions of a source document are significant, however {SourceCharacter}
-which appear in {Ignored} may also appear within a lexical {Token} in a
-significant way, for example a {StringValue} may contain white space characters.
-No {Ignored} may appear _within_ a {Token}, for example no white space
-characters are permitted between the characters defining a {FloatValue}.
+Any amount of {Ignored} may appear before and after every lexical token in a
+GraphQL document. No ignored regions of a source document are significant,
+however {SourceCharacter} which appear in {Ignored} may also appear within a
+lexical {Token} in a significant way, for example a {StringValue} may contain
+white space characters. No {Ignored} may appear _within_ a {Token}, for example
+no white space characters are permitted between the characters defining a
+{FloatValue}.
 
 **Byte Order Mark**
 
 UnicodeBOM :: "Byte Order Mark (U+FEFF)"
 
-The _Byte Order Mark_ is a special Unicode code point which may appear at the
+:: The _Byte Order Mark_ is a special Unicode code point which may appear at the
 beginning of a file which programs may use to determine the fact that the text
 stream is Unicode, and what specific encoding has been used. As files are often
 concatenated, a _Byte Order Mark_ may appear before or after any lexical token
-and is {Ignored}.
+and is {Ignored}. {UnicodeBOM} is forbidden within a _schema coordinate_.
 
 ### Punctuators

Ultimately I decided that section 2 of the spec is about the GraphQL language (for GraphQL documents) which does not specifically relate to schema coordinates, and so instead of talking about schema coordinates in section 2 before they are introduced, I would instead have schema coordinates reference section 2 and apply the exception on top. I'm not sure if this is the right decision - @leebyron would be able to better weigh in here - but if we are to comment in section 2 then here are the kind of changes that I would have made (i.e. adding "in a GraphQL document" to differentiate such from a "schema coordinate").

@magicmark magicmark force-pushed the schema_coordinates_spec_edit branch from e4bdce8 to c8375f0 Compare July 4, 2025 22:37
@magicmark
Copy link
Contributor Author

magicmark commented Jul 4, 2025

ack @benjie

section 2 of the spec is about the GraphQL language (for GraphQL documents) which does not specifically relate to schema coordinates

makes sense, I was wondering about this too. seems overkill I agree, but something may be in order.

Anyway I've removed it from this PR for now, and made a separate follow-up PR that can be merged on top of this, should we decide this clarification (or similar) is appropriate. magicmark#2

@magicmark
Copy link
Contributor Author

Updated the spec + implementation (graphql/graphql-js#4463) per the last meeting.

Copy link
Member

@benjie benjie left a comment

Choose a reason for hiding this comment

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

Looking good! Here's some editorial changes that I'd recommend

@benjie
Copy link
Member

benjie commented Aug 28, 2025

Note: I guessed at the anchor tags to use in this; please check they're valid 😅

leebyron and others added 2 commits August 31, 2025 22:10
Co-authored-by: Benjie <benjie@jemjie.com>
@leebyron leebyron force-pushed the schema_coordinates_spec_edit branch from 1347a1e to c41e64f Compare September 1, 2025 05:41
@leebyron leebyron force-pushed the schema_coordinates_spec_edit branch from 1a71923 to 580d292 Compare September 1, 2025 05:47
@leebyron leebyron force-pushed the schema_coordinates_spec_edit branch from 12c7bfc to 959fe1b Compare September 1, 2025 05:49
leebyron added a commit to graphql/graphql-js that referenced this pull request Sep 1, 2025
Depends on #3115

Implements graphql/graphql-spec#794

Adds:

* DOT punctuator in lexer
* Improvements to lexer errors around misuse of `.`
* Minor improvement to parser core which simplified this addition
* `SchemaCoordinate` node and `isSchemaCoodinate()` predicate
* Support in `print()` and `visit()`
* Added function `parseSchemaCoordinate()` since it is a parser entry
point.
* Added function `resolveSchemaCoordinate()` and
`resolveASTSchemeCoordinate()` which implement the semantics (name
mirrored from `buildASTSchema`) as well as the return type
`GraphQLSchemaElement`

---------

Co-authored-by: Benjie Gillam <benjie@jemjie.com>
Co-authored-by: Mark Larah <mark@larah.me>
Co-authored-by: Yaacov Rydzinski <yaacovCR@gmail.com>
@leebyron leebyron merged commit 1e29b8a into graphql:main Sep 1, 2025
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🏁 Accepted (RFC 3) RFC Stage 3 (See CONTRIBUTING.md)
Projects
None yet
Development

Successfully merging this pull request may close these issues.