Rejects schemas where $ref refers to $id or $anchor

[sam-mccall]

Describe the bug

When processing schemas, the server seems to assume that the hash part a $ref is always a JSON pointer.

Therefore the following schema can't be loaded, with an error $ref 'A' in 'file:///...' can not be resolved.

Schema:

{
  "$schema": "http://json-schema.org/draft-07/schema",
  "type": "object",
  "properties": {
    "A": { "$id": "#A", "type": "string" },
    "B": { "$ref": "#A" }
  }
}

Example valid doc:

# yaml-language-server: $schema=fail.schema.json
A: foo
B: bar

Expected Behavior

Schema loads and document validates correctly.

The draft-07 spec says:

Schemas can be identified by any URI that has been given to them, including a JSON Pointer or their URI given directly by "$id".

and goes on to give a very similar example.

Current Behavior

Language server shows the error: $ref 'A' in 'file:///...' can not be resolved.

For the 2019 JSON-schema spec, we should use "$anchor": "A" instead of "$id": "#A"`. This also doesn't work.

Using a JSON-pointer link "$ref": "/properties/A" does work.

Steps to Reproduce

1. Save the files above as fail.schema.json and fail.yaml
2. Open fail.yaml in an editor talking to yaml-language-server
3. See spurious diagnostics on the first line of content

Environment

• Windows
• Mac
• Linux
• other (please specify)

[sam-mccall]

Browsing the code findSection() looks suspicious: it seems ids/anchors would have to be handled somewhere near there, rather than just assuming the hash fragment is a JSON pointer.

[gorkem]

We are using vscode-json-langaugeservice to resolve schemas. This has been fixed upstream, we probably need to adjust to this later version.