JSON Schema Draft v4 Section 7.2.2.

[sgpi...@gmail.com]

Section 7.2.2. of the current draft v4 spec describes using the id keyword to "alter resolution scopes". An example is given. The spec states that JSON schema docs have "Base URIs" that are URIs according to RFC3986, and that the id keyword alters this base URI. However it does not state that "altering resolution scopes" is intended to be consistent with Relative URI Resolution described in RFC3986 (URIs section 5.2). Is it?

I think the example given is not detailed enough to unequivocally get across the exact behavior of the "altering resolution scopes" algorithm. I think this example could easily be made a bit more detailed to get across the intended behavior of of scope resolution whether or not the its intended to be consistent with RFC3986 relative URI resolution. Going by the example it appears that the scheme propose isnot consistent with RFC3986. Specifically, there is no difference between  "/foo" (absolute path), and "foo" (relative path).

Another question one walks away with is that of relative fragments. AFAIK RFC3986 relative URI resolution does not describe a scheme for relative fragments, but such a thing just intuitively seems useful in JSON Reference. The spec and the example does not give enough detail for one to be confident one way or the other.

Could someone please clarify the scheme for "altering resolution scopes" (i.e. updating the base URI)?

Thanks,

Sam.

[Austin Wright]

The term "resolution scope" is a poor term, the behavior in RFC3986 ought to be normative (and arguably is, even if we define it otherwise). Hopefully that will be fixed in the next draft.

There's no such thing as a "relative fragment", do you have an example? I'm guessing the fragment you're thinking of is, in actuality, invalid.

Austin.

[Sam Pinkus]

On 07/27/2015 05:52 AM, Austin Wright wrote:

The term "resolution scope" is a poor term, the behavior in RFC3986 ought to be normative (and arguably is, even if we define it otherwise). Hopefully that will be fixed in the next draft.

Yeah I think the spec should be amended to just defer to RFC3986. Relative URI resolution is quite rigorously defined there. I would bet most implementers simply refereed to the RFC3986 spec anyway, disregarding the ambiguous section 7.2.2.

There's no such thing as a "relative fragment", do you have an example? I'm guessing the fragment you're thinking of is, in actuality, invalid.

No such thing in RFC3986. What I was thinking was:

    "definitions": {
        "positiveIntegerArray": {
            "type": "array",
            "minItems": 1,
            "items": { "$ref": "#positiveInteger" }
        },
        "positiveInteger": {
            "type": "integer",
            "minimum": 0
        },

The "#positiveInteger" ref is relative to its containing scope. If the JSON schema spec clearly deferred to RFC3986, it would stop people drifting off and thinking this type of thing might be valid. A slightly more detailed example could also rule this out.

Thanks,

Sam

--

PGP: 0xA53455C1