v6 hyper-schema: baseUri

[handrews]

Originally proposed by @geraintluff at https://github.com/json-schema/json-schema/wiki/baseUri-(v5-proposal)
The content below is exactly as it appears on the old wiki:

Proposed keywords

• baseUri

Purpose

For convenience, specify a base URI against which schema-defined links will be resolved. This allows shorter href values.

Values

baseUri must be a URI Template (resolved against current base URI, or request URI).

(v4 actually mentioned that rel="self" links could be used for this, but that's not ideal.)

Example

{
    "baseUri": "/items/{id}/",
    "links": [
        {
            "rel": "comments",
            "href": "comments/"
        },
        {
            "rel": "related",
            "href": "related/"
        }
    ]
}

Concerns

Does this propagate into children? Either:

• You have to also specify baseUri for every schema that defines links
• baseUri applies to the data - at which point, what if multiple schemas have multiple values? Ideally, each schema would use its own baseUri for its own links, but that gets complicated when it comes to child properties.

[handrews]

Having thought about this proposal for a while, I find it more confusing than it's worth. There's the child-propagation concern, and the complications mentioned there. It also is saving just a few keystrokes per URI at the cost of substantial readability. Having to mentally assemble the URI across several fields (which may be many lines apart) is much harder to work with than just seeing the URI template at the point where you need it.

I'm solidly (although not vehemently) against this proposal.

[handrews]

Did this get put in the latest draft as base without actually finishing the discussion or resolving the issue?

[awwright]

Uh... yeah, yeah it did. I must have missed this issue.

The functionality was already in JSON Hyper-schema as a special case for links where rel="self", which is somewhat unprecedented, since links shouldn't be changing the document's behavior just by existing. I can't really take the behavior out (it's used by JSON Schema itself), so it was just spun into a keyword.

We'll see if it works out or not.

[handrews]

LOL that's a good reason to have added it!

FWIW I'm not as opposed to it as I was in the earlier comment. There's a bit of weirdness (to me) with all of these resolution scope-changing keywords, but I think some early bad experiences with id has led me to be too harsh on the concept.