v6 hyper-schema: propertyLinks about json-schema-spec HOT 5 CLOSED

It's been more than two weeks since this was put up for adoption with no takers, and two of us against the proposal. Closing.

from json-schema-spec.

An alternative proposal would be to just use the existing LDO approach with a JSON Pointer fragment URI. While slightly less clear, it has the advantage of putting all links, local or not, in the same format. It also avoids the duplication problem.

from json-schema-spec.

This needs a really good example of why this would be useful.

If you want to express a relationship between the two, you should give the two instances URIs, then create a link using those URIs.

Is there ever a case where we don't want to give the instances URIs, but still allow software to see a relationship? That sounds really far-fetched

from json-schema-spec.

Is there ever a case where we don't want to give the instances URIs, but still allow software to see a relationship? That sounds really far-fetched

Not that I can think of.

Are we agreeing on the solution here? I meant something like:

{
    "title": "Programming project",
    "description": "A description of a programming project",
    "type": "object",
    "properties": {
        "id": {"type": "integer", "minimum": 1},
        ...,
        "author": {"$ref": "/definitions/user"}
    },
    "links": [
        {
            "rel": "self",
            "href": "/projects/{id}"
        },
        {
            "title": "Author",
            "rel": "http://schema.org/author",
            "href": "#/author"
        }
    ]
}

Which I think says "There is a link from this instance at https://api.example.com/projects/12345 to an author at https://api.example.com/projects/12345/#/author"

Is that what you had in mind? As much as I hate HTML analogies, I'll make one here- this is the equivalent of <a href="#foo">link to foo</a> and <a name="foo">this is foo</a> (or id instead of name in HTML5).

from json-schema-spec.

@awwright , @Relequestual , anyone else: Does anyone want to adopt this proposal? @awwright and I are both against the proposed solution. I commented on another approach but if that approach is needed or valid at all, it does not require any changes to the spec.

If no one speaks up within two weeks, I will close this issue.

from json-schema-spec.