Add callout that external subschema approach is not prohibited.

[yaacovCR]

I'm overall not convinced that the way the specification is designed should match how it is used. Most teams/groups using composition may be "in control" of all of the different subchemas/source schemas, but I'm not convinced that this definitely so; perhaps they are "in control" of most of them but want to link to popular 3rd party APIs, Github/Stripe, etc. Since the problem of connecting arbitrary subschemas is a superset of what the specification currently proposes, I think it would make sense to start there, as otherwise the specialized case crowds out the more general.

So I would be in favor of a more generic specification that describes how multiple GraphQL schemas can be composed, and then leave room for additional tooling that might be helpful for those teams that are truly "in control" of all of their subschemas, and am leaning against the vision suggested here.

On the other hand, this PR introduces a small change that just highlights that it should be possible to transform arbitrary schemas into compliant source schemas, which I think might bridge the overall gap.

[smyrick]

On the other hand, this PR introduces a small change that just highlights that it should be possible to transform arbitrary schemas into compliant source schemas, which I think might bridge the overall gap.

I think this is the gap that we should call out in the spec (maybe in other sections), but that we don't need to solve and leave that to other on how you do schema transforms.

Lets say I do want to use the Stripe GraphQL API. I can download the schema to be used in my composed graph, but we don't want to force companies to add support for this composition spec in their public schema. There is also the fact that you can't really get directive metadata today.

Our spec should make sure that you can make a schema that does not have any composer support compatible with explicit directives (like @finder) and adding those directives to the schema can be done with standard GraphQL extensions or some external transformer library.

[yaacovCR]

@smyrick I'm not sure if we are disagreeing here; I read your comment that you are agreeing with the small edit I am making in this PR. To run with your example, the spec currently is sort of saying that integrating the Stripe GraphQL API is out of scope; with this edit, it is saying that it is in scope inasmuch as a team can make itself responsible for maintaining the external API as a compliant source schema, by adding directives themselves through a transformation and owning all of the implications of that.

[smyrick]

You are correct. I apologize as I am new to the WG and how to separate discussions from spec change proposals. The edits you made here look good to me. I am calling out where we might want to consider adding more language elsewhere, but as the WG works through the different sections we can get specifics.

[yaacovCR]

No apology necessary!!!! Your comments have been super helpful, just want to make sure we are on the same page. :)

[benjie]

Here's a suggested alternative way of stating this, I think the even as may be hard to parse for some readers and the may would be considered a usage of RFC2119 currently so I wanted to make this a Note to make it non-normative.

[benjie]

spec-md does not support double-space forced newlines because Lee doesn't like that that's a feature of Markdown.

Also, I'm not sure this will work correctly as a "Note" callout under spec-md in this position? I'd have to render it with spec-md to be sure, but I think it would be better somewhere after the bulleted list?

[glen-84]

It renders like this:

If you add an empty line before the note, you get:

Better, but ideally it would be indented.

[michaelstaib]

I think this note is necessary. Tools can always add preprocessing to the process.

Stale