File URIs with pointer fragments

[gregsdennis]

I'm not sure if this is a universal thing, but .Net apparently doesn't allow fragments for file:// URIs. It seems to URI-encode the # into the file name, making extracting a fragment difficult.

Ref: json-everything/json-everything#427

Is this something that we should have a test for?

Edit:

For a bit more information, my implementation combines the base URI with the $ref URI to get the full URI to resolve.

With a base URI of file:///c:/folder/file.json and a $ref of #/definitions/foo, that combining step (which uses .Net code, not mine) results in file:///c:/folder/%23/definitions/foo instead of file:///c:/folder/file.json#/definitions/foo; the file.json is replaced by the encoded # (%23) and it's now looking for a new file and fails to resolve.

[Julian]

Sounds good to me, though I don't think we can represent that here at the minute, even in optional, as we don't have a way of assigning arbitrary URIs in the "core" test suite. (This is similar to why we don't have remote $ref URN URI tests). Could go into https://github.com/python-jsonschema/referencing-suite certainly, or we could of course revisit trying to figure out the least possibly invasive way to add tests like that.

[gregsdennis]

Can we not just add "$id": "file:///c:/folder/file.json" to the schema? (Granted that's a windows file URI; maybe we need both.)

[Julian]

Oh I see, yes that definitely is a thing we can do. For some reason I assumed this was about retrieval URIs. +1

[jdesrosiers]

Is it really correct that file: URIs can't have fragments? Fragment is part of the generic URI structure. I think every scheme needs to at least allow them in order to be a valid URI.

If fragments weren't allowed in file: URIs, that would make them nearly useless with JSON Schema. A simple local reference to $defs wouldn't be allowed. The only thing that would work would be an external reference with no fragment.

[gregsdennis]

Is it really correct that file: URIs can't have fragments?

It might just be a .Net thing. I don't know. Regardless, since at least one environment doesn't allow it (or at least treats them weirdly), it seems prudent to have a test to ensure they're supported.

[joooeey]

Is it really correct that file: URIs can't have fragments? Fragment is part of the generic URI structure. I think every scheme needs to at least allow them in order to be a valid URI.

If fragments weren't allowed in file: URIs, that would make them nearly useless with JSON Schema. A simple local reference > to $defs wouldn't be allowed. The only thing that would work would be an external reference with no fragment.

RFC 3986 URI Generic Syntax appears to imply that a scheme specification (e.g. file:) has no say in how to interpret fragments, so it can't forbid them:

[...] Fragment identifier semantics are independent of the URI scheme
and thus cannot be redefined by scheme specifications.

Individual media types may define their own restrictions [...]

[...]

As such, the fragment identifier is not used in the scheme-specific
processing of a URI; instead, the fragment identifier is separated
from the rest of the URI prior to a dereference, and thus the
identifying information within the fragment itself is dereferenced
solely by the user agent, regardless of the URI scheme.

However, RFC 8089 The "file" URI Scheme
doesn't mention fragments at all. This makes sense from a purely logical perspective
but that way developers easily overlook file: URIs may include fragments.
Therefore it might not work well with all software.
Chrome and Edge correctly resolve the fragment in
file:///%HOMEPATH%/Downloads/RFC 3986_ Uniform Resource Identifier (URI)_ Generic Syntax.html#section-3.5
However, the file explorer manages to tell the browser to open the HTML but it doesn't scroll down.

So the test case is indeed sensible.