The current validation rules for directive collisions in schema composition, specifically EXTERNAL_COLLISION_WITH_ANOTHER_DIRECTIVE and OVERRIDE_COLLISION_WITH_ANOTHER_DIRECTIVE, appear to be both inconsistent and incomplete.

Current Behavior

Rules and Algorithms

1. OVERRIDE_COLLISION_WITH_ANOTHER_DIRECTIVE

   - Let {schemas} be the set of all source schemas to be composed.
   - For each {schema} in {schemas}:
     - Let {types} be the set of all composite types in {schema}.
     - For each {type} in {types}:
       - Let {fields} be the set of fields on {type}.
       - For each {field} in {fields}:
         - If {field} is annotated with `@override`:
           - {field} must **not** be annotated with `@external`
   

2. EXTERNAL_COLLISION_WITH_ANOTHER_DIRECTIVE

   - Let {schemas} be the set of all source schemas to be composed.
   - For each {schema} in {schemas}:
     - Let {types} be the set of all composite types in {schema}.
     - For each {type} in {types}:
       - Let {fields} be the set of fields on {type}.
       - For each {field} in {fields}:
         - If {field} is annotated with `@external`:
           - For each {argument} in {field}:
             - {argument} must **not** be annotated with `@require`
           - {field} must **not** be annotated with `@provides`
   

Issues with the Current Rules

1. Inconsistent Scope:

   • OVERRIDE_COLLISION_WITH_ANOTHER_DIRECTIVE focuses specifically on @override and @external collisions, while EXTERNAL_COLLISION_WITH_ANOTHER_DIRECTIVE handles @external with @require and @provides.
   • Why does @override have its own rule, while other directive collisions are grouped under EXTERNAL_COLLISION_WITH_ANOTHER_DIRECTIVE?

2. Ambiguity:

   • It’s unclear which directives fall under the scope of each rule. This makes understanding and maintaining these rules challenging.

Proposal

Introduce a separate rule for each combination of directives. Examples:

1. EXTERNAL_OVERRIDE_COLLISION:
2. EXTERNAL_PROVIDES_COLLISION:
3. EXTERNAL_REQUIRE_COLLISION: