On Wed, May 13, 2009 at 3:55 PM, Nikunj Mehta <[email protected]> wrote: > > > On May 13, 2009, at 1:14 PM, Martin Atkins wrote: > >> >> 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. > > 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. > >> >> >>> 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. >> >> 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?
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 l...@type (as you mention below) is indeed meant to be just a hint, it seems to me that @r...@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 a...@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. > >> >> 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. >> > > 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. > >
