Subject: Proliferation of rel values for atom:link

From: Nikunj Mehta <[email-masked]>
Date: Wed, 13 May 2009 11:39:27 -0700

One of the challenges facing client developers, including us, is the  
limitless proliferation of rel values for atom:link. The problem is  
that everyone abuses the rel value mechanisms of atom:link. While we  
shouldn't attempt to stop this, where new public standards are being  
created we ought to act more prudently.

Specifically, I suggest that new standard rel values be used for  
introducing new features in Atom's data model. For example, dealing  
with hierarchy/containment requires the use of new rel values because  
using any other value will completely trash the existing definition of  
that value.

On the other hand, applications may use Atom's category term attribute  
to ascribe computer-readable meaning to the specific link. For  
example, CMIS shows a good number of such examples where a single  
folder entry can have children of four different kinds - policies,  
relationships, documents, and descendants [1].

The IETF should not blindly register new link relation values for each  
of these types of children. Instead, the IETF should exhaust existing  
link relations or see if there is a need for a new general purpose  
link relation value. This way, the new value will have uses far beyond  
the specific application introducing that value.

As an example, consider the following solution to the CMIS requirement  
where I am using hierarchy-ID's rel=detail and rel=related:
<entry xmlns="..." xmlns:h=".../">
   <title>A folder entry</title>
   <id>...</id>
   <updated>...</updated>
   <author><name>John Doe</name></author>
   <content src="..."/>
   <link rel="self" href="/folder;metadata"/>
   <link rel="edit" href="/folder;metadata"/>

   <link rel="detail" h:count="0"
     title="Folder children collection"
     href="/folder;contents/" term="http://www.oasis-open.org/cmis#contents 
"/>
   <link rel="detail" h:count="0"
     title="Folder relationships collection"
     href="/folder;relationships/" term="http://www.oasis-open.org/cmis#relationships 
"/>
   <link rel="detail" h:count="0"
     title="Folder policy collection"
     href="/folder;policies/" term="http://www.oasis-open.org/cmis#descendants 
"/>
   <link rel="related" h:count="0"
     title="Folder descendants feed"
     href="/folder;descendants/" term="http://www.oasis-open.org/cmis#descendants 
">
</entry>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 13 May 2009 21:05:02 +0200

Nikunj Mehta wrote:
> ...
> to ascribe computer-readable meaning to the specific link. For example, 
> CMIS shows a good number of such examples where a single folder entry 
> can have children of four different kinds - policies, relationships, 
> documents, and descendants [1].
> ...

As far as I can tell, @term is only allowed on atom:category? Are you 
proposing to change that?

If so: -1 -- we shouldn't introduce a new dimension on links; the name 
of the relation plus the link target (media type, XML namespace, 
whatnot) should be sufficient.

BR, Julian

---

From: Nikunj Mehta <[email-masked]>
Date: Wed, 13 May 2009 12:04:22 -0700

As Julian pointed out on my blog, I can't use Atom's term attribute on  
atom:link. This changes the example below (r/term/h:kind, a new  
attribute), but does not alter the principle I am espousing.

Nikunj
On May 13, 2009, at 11:39 AM, Nikunj Mehta wrote:

> with hierarchy/containment requires the use of new rel values  
> because using any other value will completely trash the existing  
> definition of that value.
>
> On the other hand, applications may use Atom's category term  
> attribute to ascribe computer-readable meaning to the specific link.  
> For example, CMIS shows a good number of such examples where a  
> single folder entry can have children of four different kinds -  
> policies, relationships, documents, and descendants [1].
>
> The IETF should not blindly register new link relation values for  
> each of these types of children. Instead, the IETF should exhaust  
> existing link relations or see if there is a need for a new general  
> purpose link relation value. This way, the new value will have uses  
> far beyond the specific application introducing that value.
>
> As an example, consider the following solution to the CMIS  
> requirement where I am using hierarchy-ID's rel=detail and  
> rel=related:

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: Wed, 13 May 2009 12:22:50 -0700

On May 13, 2009, at 12:05 PM, Julian Reschke wrote:

>> attribute to ascribe computer-readable meaning to the specific  
>> link. For example, CMIS shows a good number of such examples where  
>> a single folder entry can have children of four different kinds -  
> As far as I can tell, @term is only allowed on atom:category? Are  
> you proposing to change that?
>

No I am not

> If so: -1 -- we shouldn't introduce a new dimension on links; the  
> name of the relation plus the link target (media type, XML  
> namespace, whatnot) should be sufficient.

Intermediaries such as libraries, synchronization tools, and  
aggregators won't understand 10,000 new link relations that every  
vendor dealing with AtomPub is currently producing. IMHO, the rel  
value should be understandable to intermediaries not only end points.

How is introducing another dimension for application-specified text  
worse than creating a huge number of non-standard rel values? It  
doesn't break any existing clients or servers.

We have encountered this issue while building synchronization tools,  
but I suspect similar issues crop up for other intermediaries too.

Nikunj

---

From: Martin Atkins <[email-masked]>
Date: Wed, 13 May 2009 13:14:31 -0700

Nikunj Mehta wrote:
> 
> Intermediaries such as libraries, synchronization tools, and aggregators 
> won't understand 10,000 new link relations that every vendor dealing 
> with AtomPub is currently producing. IMHO, the rel value should be 
> understandable to intermediaries not only end points.
> 

If an intermediary is Atom-generic then it should not be attempting to 
understand link relations. A library would ideally provide an interface 
to retrieve links by (rel, type) pair, possibly also allowing 
constraining by hreflang.

The meaning of specific values of rel is for endpoints to determine, not 
intermediaries. Intermediaries should just be concerned with getting the 
data from A to B without loss of meaning.

> worse than creating a huge number of non-standard rel values? It doesn't 
> break any existing clients or servers.
> 

Adding a new attribute to link seems likely to break more intermediaries 
than adding new rel values. Existing libraries will likely not provide a 
convenient means to access the new attribute, and entry re-publishing 
systems may drop the new attribute on the floor when the entry 
round-trips through their data model.

However, I do agree with your general principle that new link 
relationships should be generic and not specific to a given application. 
rel and type are two orthogonal dimensions that should be considered 
together by applications.

---

From: Nikunj Mehta <[email-masked]>
Date: Wed, 13 May 2009 13:55:28 -0700

On May 13, 2009, at 1:14 PM, Martin Atkins wrote:

> If an intermediary is Atom-generic then it should not be attempting  
> to understand link relations. A library would ideally provide an  
> interface to retrieve links by (rel, type) pair, possibly also  
> allowing constraining by hreflang.

Why so? We see tremendous value in interpreting rel values for pre- 
fetching certain data that we feel may be useful to the user.

>
> The meaning of specific values of rel is for endpoints to determine,  
> not intermediaries. Intermediaries should just be concerned with  
> getting the data from A to B without loss of meaning.

I am using the term intermediaries rather loosely here. See above for  
what I mean by the term. When an application produces a variant of  
AtomPub for interaction between server A and client B, A and B are the  
endpoints. However, if a standard client C wants to play with server  
A, it would be useful if it didn't have to fully understand all the  
customizations introduced by A.

> Adding a new attribute to link seems likely to break more  
> intermediaries than adding new rel values.

What intermediaries would break if they see new attributes on links?  
Can you relate your experience with this issue?

> Existing libraries will likely not provide a convenient means to  
> access the new attribute, and entry re-publishing systems may drop  
> the new attribute on the floor when the entry round-trips through  
> their data model.

Dropping foreign mark-up is a boo-boo in Atom, whether it is in  
clients or servers.

> relationships should be generic and not specific to a given  
> application. rel and type are two orthogonal dimensions that should  
> be considered together by applications.
>

I am not sure what you mean by type - it is optional and merely a hint  
for the Content-Type of the representation obtained at the href.

---

From: Peter Keane <[email-masked]>
Date: Thu, 14 May 2009 00:11:01 -0500

On Wed, May 13, 2009 at 3:55 PM, Nikunj Mehta <[email-masked]> wrote:
>>> won't understand 10,000 new link relations that every vendor dealing with
>>> AtomPub is currently producing. IMHO, the rel value should be understandable
>>> to intermediaries not only end points.
>>
>> understand link relations. A library would ideally provide an interface to
>> retrieve links by (rel, type) pair, possibly also allowing constraining by
>> hreflang.
>
> Why so? We see tremendous value in interpreting rel values for pre-fetching
> certain data that we feel may be useful to the user.
>
>>
> I am using the term intermediaries rather loosely here. See above for what I
> mean by the term. When an application produces a variant of AtomPub for
> interaction between server A and client B, A and B are the endpoints.
> However, if a standard client C wants to play with server A, it would be
> useful if it didn't have to fully understand all the customizations
> introduced by A.
>
>>
>>
>>> How is introducing another dimension for application-specified text worse
>>> than creating a huge number of non-standard rel values? It doesn't break any
>>> existing clients or servers.
>>
>> than adding new rel values.
>
> What intermediaries would break if they see new attributes on links? Can you
> relate your experience with this issue?

I'm not sure I've taken part in any detailed discussion of Atom Syntax
that did not eventually bring up the need for link extensions :-).  It
is certainly a recurring issue, and I think some thought should be
given about how to deal with it.  For the @rel attribute, of course,
anyone can mint a new one if they use a full URI.  And while link@type
(as you mention below) is indeed meant to be just a hint, it seems to
me that @rel+@type do indeed offer a handy mechanism for
distinguishing.  Atom:link also has @title, which could certainly be
of use in some cases, although one would assume that would involve
human interpr. (it's used effectively in the Atom Media Extension
proposal).

Adding attributes is a possible solution, but I'd be wary of a
proliferation of these (everyone seems to want 'em).  It may be the
only solution, but it would be nice if the work done here and in
Activity Streams (and Atom Media extensions ), as well as Snell's Atom
Link Extensions draft were harmonized.  Were it up to me, I'd probably
suggest using atom:category as a child of atom:link (that's undefined,
but not disallowed in the current spec)  to distinguish link "kinds"
or to express attributes of the link beyond that expressed in @rel +
@type.

Whatever happens, I do hope we can come up with a reasonable mechaism
to extend atom@link (hopefully a mechanism that'll provide guidance
for many of the various efforts wanting to extend it).

--peter keane

>
>> Existing libraries will likely not provide a convenient means to access
>> the new attribute, and entry re-publishing systems may drop the new
>> attribute on the floor when the entry round-trips through their data model.
>
> Dropping foreign mark-up is a boo-boo in Atom, whether it is in clients or
> servers.
>
>>
>> relationships should be generic and not specific to a given application. rel
>> and type are two orthogonal dimensions that should be considered together by
>> applications.
>>
>
> I am not sure what you mean by type - it is optional and merely a hint for
> the Content-Type of the representation obtained at the href.
>
>