Types, rels, and other types

[randallsquared]

We currently have

• rel for link relations
• h:link.template.fields[key].type for form/template field hinting
• h:link.template.contentType for mimetype of requests
• h:type for... something kind of like link relations, but applying to specific values, and possibly also including datatypes

The h:type language suggests that there is some vocabulary of basic type indicators, but this is, as far as I can tell, not the case. Siren punts to HTML5 types for the equivalent of h:link.template.fields[key].type, which imports an enormous amount of complexity into the spec, in my opinion.

• Should we unify h:link.template.fields[key].type and h:type?
• Should we unify rel and h:type?

If neither, then we should definitely put more description in the h:type definition about what "standard types" are.

[inadarei]

Ha! We had almost identical discussion when designing UBER.

1. Easy things first, h:link.template.fields[key].type and h:type are very different animals. The former is basically enumeration of HTML Form's various field types. The latter (h:type) is more akin to class type for an entity embedded in the message. I think naming similarity aside, they are significantly different.
2. `h:type: is basically like "rel" but rel explains type of relationship, whereas "type" explains the nature of a fragment of the message. So they are not exactly the same thing, either.

Remembering discussion in UBER, the suggestions were:

1. To call the field explaining local semantics role and keep it separate from rel, since rel is a well-established general notion and repurposing it for new needs can be a bad idea.
2. Since this thing is "rel but local", call both "rel".

I believe in UBER the choice #2 won. That said - it is a different media type with different spirit. In case of Hyper, I think it is more appropriate to stick to the very well-defined understanding of rel and introduce a new attribute through extension that is well-documented at its own URI h:type -> <http://uberjson.io/props/type

I believe this provides greater sense of clarity. The rel and h:type often appear very close to each other and the risk of confusion is high.

As for h:link.template.fields[key].type vs h:type the context and placement of the two are so completely detached, that I am really not worried about any confusion there. The barebones "type" may only appear in the context of a templated link (form), is well explained and I don't expect any confussion to arise there.

[inadarei]

If I am completely off here and h:type and type should, indeed, be unified then let's unify all such cases, i.e.:

1. type -> h:type
2. label -> h:label

regardless of what level you see them. This does mean that some properties of a templated link object will have h:-prefixed attributes, whereas some: won't. So there's that awkwardness, but also not the end of the world.