Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Evaluation path: relative to $ref resolved schema or resource/document root? #1482

Open
notEthan opened this issue Feb 1, 2024 · 4 comments

Comments

@notEthan
Copy link
Contributor

notEthan commented Feb 1, 2024

After traversing a $ref that contains a fragment, does the evaluation path of the resolved schema include the path between the document or resource root and the subschema indicated by the fragment?

Given, for example, this schema:

{
  "$ref": "A#/$defs/B",
  "$defs": {
    "A": {
      "$id": "A",
      "$defs": {
        "B": {
          "allOf": [
            false
          ]
        }
      }
    }
  }
}

For the referenced false schema that ultimately causes any instance to fail validation, is its evaluation path:
/$ref/$defs/A/$defs/B/allOf/0 - with its pointer relative to the referenced schema's document root
or
/$ref/$defs/B/allOf/0 - with its pointer relative to the referenced schema's resource root
or
/$ref/allOf/0 - with its pointer relative to the referenced schema
?

@notEthan
Copy link
Contributor Author

notEthan commented Feb 1, 2024

I opened this as an issue rather than a discussion because the spec seems to say nothing on this and, in my opinion, should.

@gregsdennis
Copy link
Member

The current text (for the upcoming verion) is:

Evaluation path

The evaluation path is the set of keys, starting from the schema root, through
which evaluation passes to reach the schema object that produced a specific
result. The value MUST be expressed as a JSON Pointer, and it MUST include any
by-reference applicators such as $ref or $dynamicRef.

/properties/width/$ref/allOf/1

Note that this pointer may not be resolvable on the root schema by the normal
JSON Pointer process. It is intended as an indication of the traversal path
only.

When represented in JSON, the key for this information MUST be "evaluationPath".

What's unclear to you?

The evaluation path follows through the $ref and continues at its target. It doesn't contain navigation to the target; it assumes a jump. So here, you'd get the last option you show: /$ref/allOf/0.

@notEthan
Copy link
Contributor Author

notEthan commented Feb 1, 2024

The current text

Yes, I did read the spec, thank you.

What's unclear to you?

I don't see anything in the spec addressing whether the evaluation path includes the path between $ref's resolved resource root and the schema resolved from a fragment (or even between document root and schema, though I presume not, included in the question to consider all plausible options). Stated another way, whether evaluating an anchor or pointer fragment of the $ref is considered "evaluation" for the evaluation path. The only evaluation path example using $ref in the spec points to the resource and document root.

The evaluation path follows through the $ref and continues at its target. It doesn't contain navigation to the target; it assumes a jump. So here, you'd get the last option you show: /$ref/allOf/0.

That answer makes the most sense to me, though I can also see the pointer to the fragment being useful information to include, especially for an anchor fragment. I think the spec should be clearer on this.

@gregsdennis
Copy link
Member

Yes, I did read the spec, thank you.

I was uncertain whether you were looking at 2020-12 or what's in master.

though I can also see the pointer to the fragment being useful information to include

I think you're wanting the keyword location, which is the dereferenced location and includes the base URI.

Keyword location gives you where you are; evaluation path gives you how you got there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants