Subject: link relations and links in general

From: Erik Wilde <[email-masked]>
Date: Thu, 14 May 2009 11:18:15 -0700

hello.

i know this is a bit off-list, but i am looking for pointers and 
thoughts and opinions, so i thought i'll give it a try anyway...

the recent discussions around link relations indicate a general interest 
to identify link semantics, right? and there seems to be a more general 
issue of not only identifying link semantics, but maybe generally 
possible RESTful interactions via links. for example, HTML forms use 
form/@enctype as a hint for what encoding has to be used for a form 
submission, and AtomPub uses collection/accept to indicate the MIME 
type(s). HTML forms use form/@method to indicate the supported HTTP 
method, in AtomPub it is implicit. in HTML and AtomPub, links are 
identified by the schema, but not in the markup.

what i am wondering: would it make any sense to come up with something 
like xml:id for links? something that allows XML vocabularies to be 
generically RESTful by making links discoverable and also exposing some 
minimal information about how to access those links? after all, 
hypermedia is one of the core constraints of REST, and ironically, XML 
does not have a way of identifying links.

for link relations, should there be just one well-defined list of values 
with a registry? should there be extensibility on a per application 
basis, via things like QNames or CURIEs (both of which have their issues 
because they're often not supported well in implementations).

maybe we're all still traumatized by HLink, or REST does not need any 
generic link recognition and link-enabled vocabularies are good enough. 
right now, i am just interested in some feedback about the general idea 
of "making links and some link semantics discoverable".

thanks and cheers,

erik wilde   tel:+1-510-6432253 - fax:+1-510-6425814
        [email-masked]  -  http://dret.net/netdret
        UC Berkeley - School of Information (ISchool)

---

From: Erik Wilde <[email-masked]>
Date: Thu, 14 May 2009 14:58:04 -0700

Felix Sasaki wrote:
> 2009/5/14 Erik Wilde <[email-masked] <mailto:[email-masked]>>
>     for link relations, should there be just one well-defined list of
>     values with a registry? 
> Do you have something like
> http://wiki.whatwg.org/wiki/RelExtensions
> in mind?

not really, this is HTML5 only. 
http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-05.txt 
is more what i had in mind (even though right now it unfortunately 
combines a link relation registry and their use in HTTP). i think the 
problem is exactly that we have representation-specific and sometimes 
conflicting concepts of how to talk about links. i think it would be 
useful to take something like mark's draft, remove the HTTP focus, 
extend it with more link metadata such as the "method" and "URI 
identification" mechanisms, and then define, in separate drafts, how 
this could be, for example, represented in HTTP, or in any XML 
vocabulary. like i said, this is not a concrete proposal right now, but 
something like mark's draft would be a good foundation.

more to the point of your pointer: i am wondering how exactly the wiki 
will be managed. is it strictly "add only", and once they're added, 
they're in HTML5 for good? is there some feedback or consolidation 
phase? now i see that all values say "proposed", which probably means at 
some point in time there will be a consolidation and selection phase? 
who decides, who selects, and is that selection then hardcoded into 
HTML5, like it was in HTML4? what about the overlaps in link semantics 
that will necessarily occur because many of these rel values are loosely 
defined and probably have a rather specific application background?

and then there seems to be some disconnect with HTML4. this is not a 
systematic survey, but HTML4 had "start" and this seems to have been 
renamed to "up" (at least that's my understanding) in the current HTML5 
draft. is there a list comparing HTML4 and HTML5 relation types? and if 
even HTML relation types are not consistent across versions, that's 
definitely not the direction i was interested in.

cheers,

---

From: Nikunj Mehta <[email-masked]>
Date: Thu, 14 May 2009 17:27:46 -0700

For the purposes of read-only usage, what we have with link relations  
is good enough for identifying semantics. You follow a link and issue  
a GET request and boom.. you get what you asked for.

The IANA link registry is a good enough place to hold this  
information, although it may be made even more easy to manage than to  
write to iana-assign for a new assignment. Whether that is a Wiki or  
something else, that could be discussed.

Oracle is certainly interested in putting together some kind of  
adjectives on Atom resources so that we can better predict the kind of  
operations that can be performed. For example, the edit and edit-media  
relations actually mean something beyond other link relations because  
I can actually manipulate those resources.

Likewise, the hierarchy-ID attempts to define a few new semantics for  
Atom resources that are, for lack of a better word, highlighted as  
being "master" or "detail" resources. The IETF RFC list is as good a  
place as any for recording these adjectives and the meanings of these.  
If there is a way to annotate link entries with such additional  
semantics so that we can use them even when people create separate rel  
values, we would love it.

Of course, I am approaching this from the perspective of a general  
library that wants to interpret standardized Atom extensions so that  
we can play a role when we are disconnected from the server. My blog  
talks a lot about this in the context of AtomDB [1].

Curious to hear what others think. Thanks to Eric for bringing this up  
and looking at it from a different angle.

Nikunj
On May 14, 2009, at 11:18 AM, Erik Wilde wrote:

> the recent discussions around link relations indicate a general  
> interest to identify link semantics, right? and there seems to be a  
> more general issue of not only identifying link semantics, but maybe  
> generally possible RESTful interactions via links. for example, HTML  
> forms use form/@enctype as a hint for what encoding has to be used  
> for a form submission, and AtomPub uses collection/accept to  
> indicate the MIME type(s). HTML forms use form/@method to indicate  
> the supported HTTP method, in AtomPub it is implicit. in HTML and  
> AtomPub, links are identified by the schema, but not in the markup.
>
> what i am wondering: would it make any sense to come up with  
> something like xml:id for links? something that allows XML  
> vocabularies to be generically RESTful by making links discoverable  
> and also exposing some minimal information about how to access those  
> links? after all, hypermedia is one of the core constraints of REST,  
> and ironically, XML does not have a way of identifying links.
>
> values with a registry? should there be extensibility on a per  
> application basis, via things like QNames or CURIEs (both of which  
> have their issues because they're often not supported well in  
> implementations).
>
> maybe we're all still traumatized by HLink, or REST does not need  
> any generic link recognition and link-enabled vocabularies are good  
> enough. right now, i am just interested in some feedback about the  
> general idea of "making links and some link semantics discoverable".
>
> thanks and cheers,
>

Nikunj R Mehta | Consulting Member of Technical Staff | Phone: +1 650  
506 0679 | Blog: http://o-micron.blogspot.com
Oracle Advanced Development Projects
500 Oracle Parkway #4OP662 | Redwood Shores, CA 94065
  Oracle is committed to developing practices and products that help  
protect the environment

---

From: Nikunj Mehta <[email-masked]>
Date: Thu, 14 May 2009 17:29:20 -0700

Sorry about the missing reference on the previous message. Here it is  
again.

[1] http://o-micron.blogspot.com/2008/07/uniform-data-synchronization-for-mobile.html

On May 14, 2009, at 5:27 PM, Nikunj Mehta wrote:

> For the purposes of read-only usage, what we have with link  
> relations is good enough for identifying semantics. You follow a  
> link and issue a GET request and boom.. you get what you asked for.
>
> information, although it may be made even more easy to manage than  
> to write to iana-assign for a new assignment. Whether that is a Wiki  
> or something else, that could be discussed.
>
> adjectives on Atom resources so that we can better predict the kind  
> of operations that can be performed. For example, the edit and edit- 
> media relations actually mean something beyond other link relations  
> because I can actually manipulate those resources.
>
> Likewise, the hierarchy-ID attempts to define a few new semantics  
> for Atom resources that are, for lack of a better word, highlighted  
> as being "master" or "detail" resources. The IETF RFC list is as  
> good a place as any for recording these adjectives and the meanings  
> of these. If there is a way to annotate link entries with such  
> additional semantics so that we can use them even when people create  
> separate rel values, we would love it.
>
> Curious to hear what others think. Thanks to Eric for bringing this  
> up and looking at it from a different angle.
>
> Nikunj
>> more general issue of not only identifying link semantics, but  
>> maybe generally possible RESTful interactions via links. for  
>> example, HTML forms use form/@enctype as a hint for what encoding  
>> has to be used for a form submission, and AtomPub uses collection/ 
>> accept to indicate the MIME type(s). HTML forms use form/@method to  
>> indicate the supported HTTP method, in AtomPub it is implicit. in  
>> HTML and AtomPub, links are identified by the schema, but not in  
>> the markup.
>>
>> and also exposing some minimal information about how to access  
>> those links? after all, hypermedia is one of the core constraints  
>> of REST, and ironically, XML does not have a way of identifying  
>> links.
>>
> Nikunj R Mehta | Consulting Member of Technical Staff | Phone: +1  
> 650 506 0679 | Blog: http://o-micron.blogspot.com
>  Oracle is committed to developing  
> practices and products that help protect the environment
>

---

From: Hadrien Gardeur <[email-masked]>
Date: Fri, 15 May 2009 03:04:23 +0200

Very few rel values are included in the current IANA link registry:
http://www.iana.org/assignments/link-relations/link-relations.xhtml
For values defined in a RFC or de-facto standard values (like "service"),
the registry is useful but I'm afraid that if we turn it into a Wiki it
might get really messy with dozens of rel values, and people relying on
these values for semantics when another choice might be more appropriate (a
controlled vocabulary for example).

We might want to separate rel values used in webpages (
http://www.w3.org/TR/xhtml-modularization/abstraction.html#s_common_attrtypes)
from those used in Atom feeds too.

Hadrien

---

From: Julian Reschke <[email-masked]>
Date: Fri, 15 May 2009 10:22:33 +0200

Hadrien Gardeur wrote:
> ...
> We might want to separate rel values used in webpages 
> (http://www.w3.org/TR/xhtml-modularization/abstraction.html#s_common_attrtypes) 
> ...

On the contrary, we want to *harmonize* rel values used in HTML, Atom, 
and in HTTP Link headers!

BR, Julian

---

From: Hadrien Gardeur <[email-masked]>
Date: Fri, 15 May 2009 14:26:49 +0200

2009/5/15 Julian Reschke <[email-masked]>

> On the contrary, we want to *harmonize* rel values used in HTML, Atom, and
> in HTTP Link headers!
>
> BR, Julian
>

It'll require a very different effort to harmonize rel values between HTML
and Atom, as we'll have to redefine the scope of some of these values. For
example rel="edit" might be useful in the header of a XHTML page, but not as
defined in RFC5023 <http://tools.ietf.org/html/rfc5023>. On the other hand,
some of these values such as previous/next/first/last can easily be defined
within any context.
Hadrien

---

From: Erik Wilde <[email-masked]>
Date: Fri, 15 May 2009 08:58:58 -0700

Hadrien Gardeur wrote:
> 2009/5/15 Julian Reschke <[email-masked] 
> <mailto:[email-masked]>>
>     On the contrary, we want to *harmonize* rel values used in HTML,
>     Atom, and in HTTP Link headers!
> It'll require a very different effort to harmonize rel values between 
> HTML and Atom, as we'll have to redefine the scope of some of these 
> values. For example rel="edit" might be useful in the header of a XHTML 
> page, but not as defined in RFC5023 
> <http://tools.ietf.org/html/rfc5023>. On the other hand, some of these 
> values such as previous/next/first/last can easily be defined within any 
> context.

which is why i though maybe it would be interesting to try to identify 
"universal values", which are registered and well-defined across 
representations, as well as "format-specific values", which could 
explicitly be related to specific representations via mechanisms such as 
QNames or CURIEs (with the usual considerations about how badly both of 
these things are often handled in implementations).

cheers,

dret.