Base URI is determined incorrectly for local file schemas

[DRKV333]

According to the JSON Schema specification (https://json-schema.org/draft/2020-12/json-schema-core#section-9.1.1-3), and RFC3986 (https://www.rfc-editor.org/info/rfc3986#section-5.1.1), if a schema specifies an $id, the Base URI for relative references should come from the $id, and not from the Retrieval URI.

However, this is not the case in vscode. Consider the following project layout:

first.schema.json

{
    "$id": "http://example.com/first",
    "$schema": "https://json-schema.org/draft/2020-12/schema",
    "type": "object",
    "properties": {
        "test": {
            "$ref": "second#$defs/somestruct"
        }
    }
}

second.schema.json

{
    "$id": "http://example.com/second",
    "$schema": "https://json-schema.org/draft/2020-12/schema",
    "$defs": {
        "somestruct": {
            "type": "object",
            "properties": {
                "innerTest": {
                    "type": "string"
                }
            }
        }
    }
}

.vscode/settings.json

{
    "json.schemas": [
        {
            "url": "http://example.com/first",
            "schema": {
                "$ref": "file:///home/vince/commandpod/WrongURIBaseRepro/first.schema.json"
            }
        },
        {
            "url": "http://example.com/second",
            "schema": {
                "$ref": "file:///home/vince/commandpod/WrongURIBaseRepro/second.schema.json"
            }
        }
    ]
}

example.json

{
    "$schema": "http://example.com/first"
}

example.json produces the following warning:

Problems loading reference '$defs/somestruct': Unable to load schema from '/home/vince/commandpod/WrongURIBaseRepro/second': Schema not found: file:///home/vince/commandpod/WrongURIBaseRepro/second.

Which indicated that vscode is interpreting the reference in first.schema.json relative to its Retrieval URI, file:///home/vince/commandpod/WrongURIBaseRepro/first.schema.json, rather than its $id, http://example.com/first. (Which should ideally result in http://example.com/second, and resolve to second.schema.json through the mapping in settings.json.)

[baywet]

I ran into the exact same issue today. Here is another example

This schema contains the following:

{
  "$id": "https://spec.openapis.org/oas/3.2/schema-base/2025-11-23",
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "description": "The description of OpenAPI v3.2.x Documents using the OpenAPI JSON Schema dialect",
  "$ref": "https://spec.openapis.org/oas/3.2/schema/2025-11-23",
  "properties": {
    "jsonSchemaDialect": {
      "$ref": "#/$defs/dialect"
    }
  },
  "$defs": {
    "dialect": {
      "const": "https://spec.openapis.org/oas/3.2/dialect/2025-09-17"
    },
    "schema": {
      "$dynamicAnchor": "meta",
      "$ref": "https://spec.openapis.org/oas/3.2/dialect/2025-09-17",
      "properties": {
        "$schema": {
          "$ref": "#/$defs/dialect"
        }
      }
    }
  }
}

The resolution of both $.properties.jsonSchemaDialect and $.['$defs'].schema.properties.['$schema'] fails because they points to #/$defs/dialect. But instead of "rooting" the search at $. (because a $id is present), the language service seems to be starting its search at where the $ref is defined in both cases.

[baywet]

I did just put #345 together to address this.