Closed thejcannon closed 4 months ago
Hey there @thejcannon. This repo controls the specification itself, not any implementation. I think you're going to want to open this against the implementation that you're using. A PR here isn't going to do much.
Regarding your problem, I'm not sure exactly the problem you're facing. An example would be great.
The URI file://path
is an absolute URI. A relative URI wouldn't include the protocol, like path
, even if you expect it to be a file. It would then be resolved against the "current" URI, like file:///current/working/directory
, which ideally would have been defined or resolved earlier in the evaluation process. Using these examples, resolving the relative URI path
against the "current" absolute URI file:///current/working/directory
will yield `file:///current/working/path
.
The specification recommends against automatic loading of external schemas and data via URIs, but editors like VSCode commonly do that anyway. As a result, any behavior againt the current working directory would be specific to the editor, and the spec isn't really involved.
Oh wow yeah this is embarrassing I'm totally on the wrong repo! Not really sure how that happened 🤦
No worries @thejcannon. It happens more often than you'd think.
👋 I'm using
jsonschema
to help test some JSON schemas I have for VSCode's sake.VSCode/https://marketplace.visualstudio.com/items?itemName=tamasfe.even-better-toml seem to be fine with loading
$ref
file://
URIs as relative to CWD (or workspace root, more precisely)This seems to be an implicit behavior, inherited from
urlopen("file://path")
.LMK if you're open to a PR which special-cases
file://
URIs to potentially load relative to CWD if it isn't absolute