Behavior when "rel" is absent?

[handrews]

In draft-wright-json-schema-hyperschema-00 we made "rel" optional. Either I'm missing something, or there is no description of the behavior when "rel" is not present. Is the link to be considered untyped?

I'm not proposing any particular behavior, it just seems ambiguous enough to warrant a one sentence note somewhere.

[jdesrosiers]

In draft-wright-json-schema-hyperschema-00 we made "rel" optional

Wow, I can't believe I didn't notice that. In draft-04 it would have made sense for rel to be optional, but I'm not sure that is the case anymore.

[handrews]

In draft-04 it would have made sense for rel to be optional, but I'm not sure that is the case anymore.

Yeah, we'll have to wait for @awwright to comment as I remember him making the change but don't remember any particular discussions (or objections, for that matter). I seem to recall it making sense at the time but now I don't recall why :-P

[awwright]

It appears to be optional in RFC 5988 HTTP Linking so having it be optional would make sense.

The behavior would be the same as specified there, I don't think there's anything special we have to note, is there?

[handrews]

@awwright it's definitely optional in the HTTP link header, but per RFC 5988's introduction:

To this end, this document defines a framework for typed links that isn't specific to a particular serialisation or application.

and then

This document addresses [the non-standardness of the HTTP Link header] by re-specifying the Link header as one such serialisation, with updated but backwards-compatible syntax.

so I think that the main part of RFC 5988 doesn't say anything one way or the other about required-ness of "rel", while the HTTP link header is a serialization but not necessarily one that should be assumed as the template for all serializations. It also doesn't seem overly clear on what happens in the absence of "rel".

I think a line such as "in the absence of a relation type, an implementation MUST (SHOULD?) NOT make any assumptions about the link's semantics" would clarify the situation without overly burdening the spec.

[Anthropic]

Can I clarify my basic understanding please?

W3C html5 recommendation has "A link element must have a rel attribute".

I'm assuming now that our links section is also for the equivalent of hyperlinks which the same doc says of links without rel "This implied hyperlink has no special meaning (it has no link type) beyond linking the element's document to the resource given by the element's href attribute."

Is there anything else it is for, or does that cover it?

[handrews]

@Anthropic yes, that seems correct to me, and we could adopt similar wording.

Or we could decide that HTML, as a text media type intended as human-readable markup, is not the most suitable reference (we intentionally broke several correlations with HTML in draft-06).

The primary no-rel links being described are those specified with <a></a> anchor tags. I would argue that the text between the opening and closing tags serves as the relationship type. It is just the relationship described in human language rather than machine-friendly registries and URIs.

<div>
  You may want to visit our <a href="http://json-schema.org">project website</a>.
</div>

In this example, "project website" describes the relation expressed by the link. This is why hyperlinking "Click here" has always been bad style :-P

So I think I'm arguing that we should make rel mandatory. We don't have an analogue to HTML's anchor tag, so if we're looking to HTML I would rather follow the link tag example and require a relation type.

[jdesrosiers]

I'd prefer to keep symmetry with RFC-5988, but I wouldn't be opposed if the majority view is to make rel mandatory.

[handrews]

@jdesrosiers

RFC 5988bis, which is nearing publication, is more clear on this. The abstract link model defined in section 2 states that the link context, relation type, and target are mandatory. Target attributes are optional. But it's quite clear that they are the only optional component.

This new revision of RFC 5988 makes a much stronger distinction between the abstract model and serializations. The link header is simply one such serialization, which needs to support rev in place of rel for backwards compatibility.

However, rev is noted as deprecated in every spec that I've seen that uses it. We have no need for compatibility, so we don't need rev.

This means that we either need to make rel mandatory, or define what the default link relation type is (e.g. "related", which is the most generic possible link relation, to the point of being a tautology).

I'm happy with either solution, but we need to pick one.

My reason for preferring requiring explicit link relations is that they are an absolutely critical part of any serious hypermedia system, and forcing people to at least attempt to understand and use the field will mean more usable hyper-schemas. I have no real data on that theory, though.

[jdesrosiers]

[link relations] are an absolutely critical part of any serious hypermedia system

I disagree. If we are talking about a system that is intended for machine-to-machine communication, then yes, you are right. But, some hypermedia systems (such as the web) are intended for human consumption and don't need to be as strict. Properly creating a rel that isn't already formally defined is quite burdensome when a descriptive arbitrary string label is most effective for a human consumer.

Hopefully I'll get around to reading the Web Linking update soon. That might change my perspective.

[handrews]

Properly creating a rel that isn't already formally defined is quite burdensome when a descriptive arbitrary string label is most effective for a human consumer.

That is not my experience. I just use the tag URI scheme, and have my implementation set up so that you can configure an additional base URI for non-IANA-registered relations, so that I can use something like "tag:cloudflare.com,2017:foo" as just "foo". And tags are about as human-readable as URIs get anyway.

[awwright]

My understanding is mostly from HTML, where the bulk of links have no relation. It's just a very generic pointer, where a human has to follow it or consume it in the context of something else.

We can make it mandatory, especially if other specifications targeted towards machine consumption do. But I'm curious why?

[handrews]

@awwright in my view, while HTML has no machine-readable relation types on the vast majority of links, the human-readable text between the open and closed anchor tags serves the same role. Unlike machines, humans do not need a controlled set of relations to understand. But the text of the link is what tells us the relation, and tells us why we might want to click on the link.

Similarly, explanatory text near forms or on the submit button or something of that sort tells the human reader what sort of processing you are submitting information to.

So in my view, a relation type is always conceptually required. But in human-oriented (text/*) media types, the relation type is probably just natural language.

That doesn't make sense here, hence the need to either make it required or define a default behavior. Making it required just makes the processing a bit easier, and makes people put a bit more thought into one of the most important conceptual parts of links.

[dlax]

That doesn't make sense here, hence the need to either make it required or define a default behavior. Making it required just makes the processing a bit easier, and makes people put a bit more thought into one of the most important conceptual parts of links.

Agreed. (FWIW, I also think the analogy with HTML is a bit contrived here.)