Add support for uri fragments

[Enaero]

Json pointers which start with '#' are currently not supported. This adds support for them.

Note: I am adding a dependency on requests, but I am not sure if that comes with standard python now.

[Enaero]

@stefankoegl Could you please review this PR?

[stefankoegl]

Hi! Thanks for your contribution!

As requests is not part of the standard library, I am hesitant of adding a dependency for a single call. Can you change that to unquote from the stdlib?

Also I am not sure if it makes sense to use the same call to detect and process both kinds of json pointer representations. Can you please elaborate a bit on your use case?

[Enaero]

I can use the stdlib version. I think there's some quirks between python2 and python3 so I'll be sure to keep that in mind.

The use case is that I have json schemas which have internal refs, e.g.

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "type": "object",
  "properties": {
    "foo": { "$ref": "#/definitions/bar" }
  },
  "definitions": {
    "bar": {
      "type": "object",
      "properties": {
        "a": { "type": "string" },
        "b": { "type": "string" }
      }
    }
  }
}

I am manipulating these schemas and have a need to fetch the object pointed by the refs. rfc6901 says that it supports this type of pointer so I think it makes sense to process both kinds in the init. I am not sure I understand what you mean by using a different call.

[twm]

I don't think this is correct in its current form as it causes the JsonPointer class to accept syntax that isn't JSON Pointer.

RFC 6901 section 6 talks about how to layer the URI syntax with JSON Pointer syntax:

6.  URI Fragment Identifier Representation

   A JSON Pointer can be represented in a URI fragment identifier by
   encoding it into octets using UTF-8 [RFC3629], while percent-encoding
   those characters not allowed by the fragment rule in [RFC3986].

   Note that a given media type needs to specify JSON Pointer as its
   fragment identifier syntax explicitly (usually, in its registration
   [RFC6838]).  That is, just because a document is JSON does not imply
   that JSON Pointer can be used as its fragment identifier syntax.  In
   particular, the fragment identifier syntax for application/json is
   not JSON Pointer.

   Given the same example document as above, the following URI fragment
   identifiers evaluate to the accompanying values:

    #            // the whole document
    #/foo        ["bar", "baz"]
    #/foo/0      "bar"
    #/           0
    #/a~1b       1
    #/c%25d      2
    #/e%5Ef      3
    #/g%7Ch      4
    #/i%5Cj      5
    #/k%22l      6
    #/%20        7
    #/m~0n       8

This isn't the same thing as saying that "#" is part of the JSON Pointer syntax. Rather, you should use a URL parser such as hyperlink to parse the URL, then use the pointer from the fragment normally. For example:

from hyperlink import URL
from jsonpointer import JsonPointer

url = URL.from_text(u'#/definitions/bar')
pointer = JsonPointer(url.fragment)

Note that JSON Schema's $ref is defined to be a URI. It isn't limited to just a fragment (it may be a full URI). I don't think that you can skip the URI parser in the general case.

[Copilot]

Copilot review overview

🟡 Changes recommended

Fragment decoding occurs in the wrong order, and the new undeclared requests dependency can break imports.

Review effort: Balanced
Findings: 1 · 1

Open (2)

• Undeclared requests dependency breaks imports · New
• Decode JSON Pointer fragments before parsing · New

What changed in this PR

Adds URI-fragment JSON Pointer support to the core parser.

Changes:

• Accepts pointers beginning with #.
• Adds URI-fragment specification tests.

File	Description
jsonpointer.py	Adds fragment decoding and prefix handling.
tests.py	Covers standard URI-fragment examples.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[stefankoegl]

@copilot resolve the merge conflicts in this pull request