-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"home" link relation #41
Comments
any thoughts on this? seems like having a standardized way to link to "home documents" (whatever media type they may use) could be a useful thing to add. if you agree, i can add a section. |
if "home" is added, it might be interesting to see how it compares to the relation types proposed by http://tools.ietf.org/html/draft-wilde-service-link-rel |
The |
http://www.w3.org/TR/1999/REC-html401-19991224/types.html#type-links says that |
thinking about the relation of the proposed |
@mnot, any thoughts on this one? if you're ok, i'd be happy to contribute a PR, containing a bit of explanatory text, and the appropriate IANA registration template. |
I agree that a |
On 2016-06-16 04:18, Asbjørn Ulsberg wrote:
link relations are fuzzy by nature so it will be hard to differentiate |
for now, dret/I-D@3002e1f (the "XML syntax for home documents" draft) is where i have added the "home" link relation type. at least it's somewhere, and i'd be fine to migrate it to the core spec when/if the time seems right. |
So, what are the actual use cases here? Do you envision it occurring in representations sent to API clients (non-browser), or to browsers, or...? |
On 2016-11-23 12:21, Mark Nottingham wrote:
So, what are the actual use cases here? Do you envision it occurring in
representations sent to API clients (non-browser), or to browsers, or...?
more to non-browsers than to browsers. API people i am talking to seem
to like the idea that there's a simple way to get from any resource to a
home document (and from there potentially to additional resources such
as service documentation or description). there's not a lot of harm in
defining such a link relations, i'd say.
|
I think that makes sense. |
On 2016-11-26 23:20, Mark Nottingham wrote:
I think that makes sense.
i'll try to come up with a PR, then. the contribution process is to
update draft.md which is your "latest draft source", right?
|
As a note to this thread: I am using a Well-Known URI for the purpose of finding the home document of a server (/.well-known/home). It has less capabilities compared to a link rel, but has served me well over the years. |
On 2017-03-01 09:09, Jan Algermissen wrote:
As a note to this thread: I am using a Well-Known URI for the purpose of
finding the home document of a server (/.well-known/home). It has less
capabilities compared to a link rel, but has served me well over the years.
i am sure you are aware that this is not a registered well-known URI.
https://www.ietf.org/assignments/well-known-uris/well-known-uris.xml
however, maybe it would be a good idea to register "home" as a
well-known URI? i'll open a new issue for that.
|
PR: #214 |
@dret: That sounds like a good idea. Would you say it's okay for that |
On 2017-03-01 16:46, Asbjørn Ulsberg wrote:
however, maybe it would be a good idea to register "home" as a
well-known URI? i'll open a new issue for that.
@dret <https://github.com/dret>: That sounds like a good idea. Would you
say it's okay for that |well-known| URI to do an HTTP |301| to i.e. |/|
for applications where that make sense?
let's head over to #212 for this topic
|
#214 merged; thanks! |
would it make sense to add a "home" link relation to the home document draft? if not, should the draft maybe suggest the use of an existing one to use when linking to a home document? "start" maybe isn't terrible when just looking at the name, but then again it seems to be more "first" than "home" when looking at the definition: "Refers to the first document in a collection of documents. This link type tells search engines which document is considered by the author to be the starting point of the collection." http://www.w3.org/TR/1999/REC-html401-19991224/types.html#type-links
The text was updated successfully, but these errors were encountered: