Update wording for 6.4.1 Coercing Field Arguments

[magicmark]

This sentence doesn't quite scan as is is a little awkward to parse

[netlify]

✅ Deploy Preview for graphql-spec-draft ready!

Name	Link
🔨 Latest commit	2ad4128
🔍 Latest deploy log	https://app.netlify.com/projects/graphql-spec-draft/deploys/695c9eb6de96a7000826d547
😎 Deploy Preview	https://deploy-preview-1207--graphql-spec-draft.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[martinbonnin]

Thanks!

[benjie]

These don’t read the same to me; the existing text reads as “there may be an entry at each argument position, and if there is then its a Value or Variable” whereas the replacement seems to say “each argument position is a Value or Variable” and doesn’t as clearly allow for omission.

I think the existing text is fine as is, though it does feel slightly awkwardly phrased.

[martinbonnin]

Both read the same to me, with the new formulation being a bit easier to parse. If we want to be explicit about omission, let's add language?

Each argument position in an operation may be a literal {Value}, or a {Variable}
to be provided at runtime. Arguments may also be missing if their definition allows it.

Note that "operation" is also slightly misleading because fragments may also contain arguments. So maybe this?

Each argument position in an executable document may be a literal {Value}, or a {Variable}
to be provided at runtime. Arguments may also be missing if their definition allows it.

[magicmark]

upon rereading with fresh eyes it does make sense, but yes it's a little awkward. I like @martinbonnin's suggestions!

[benjie]

Looking at Martin's proposed edit... what is an "argument position in an executable document"? To me it's where an argument is passed to a field in a document (which is irrespective of the actual type system - the field doesn't even need to exist in the schema):

query {
  __nonsenseDoesNotExistField__(arg: >>>THIS IS AN ARGUMENT POSITION IN AN EXECUTABLE DOCUMENT<<<<)
}

As such, it can only be a literal or a variable... there's no other option. So I think Martin's second option can be simplified a bit, it's informational (contains) rather than normative (may):

Each argument position in an executable document may be contains a literal {Value}, or a {Variable}
to be provided at runtime. Arguments may also be missing if their definition allows it.

However, I feel like the "argument position in an executable document", whilst much more concrete, is potentially meaning something different than that which the previous text implied, so I think Martin's additional clarifying sentence might be needed - but we shouldn't rely on validation here ("if their definition allows it") since execution is allowed to be performed without validation. A "for example" might be a softer way of writing this:

Suggested change

	Each argument position in an operation may be a literal {Value}, or a {Variable}
	to be provided at runtime.
	Each argument position in an executable document contains a literal {Value}, or
	a {Variable} to be provided at runtime. Some arguments may not be represented
	in the document, for example if they are optional.