Subject: Sponsored Links and other link extensions

From: James M Snell <[email-masked]>
Date: Fri, 21 Oct 2005 11:43:54 -0700

Ok, now that a number of the other extensions I've been working on are 
moving along, it's time to turn my attention to a couple of other ideas 
I've been stewing on.  One of which is link[rel="sponsored"] to indicate 
sponsored links / advertisements within feeds.

  <link rel="sponsored" 
href="http://someone.is.paying.for.me.to.put.this.here" />

The reason for not using rel="related" here is to provide consumers a 
clear distinction between links that are truly related to the entry vs. 
links included as advertisements.

A feed, entry or source may contain any number of rel="sponsored" links.

Further, many links can be augmented with graphics and extended 
descriptions, for this purpose, I am considering a couple of new 
extension elements that would be children of atom:link

  <link rel="sponsored" href="...">
    <x:image type="">...</x:image>
    <x:documentation type="text|html|xhtml">Some basic documentation 
about the link</x:documentation>
  </link>

The x:image element would specify the URI of an image file (aspect ratio 
of 2:1) associated with the link.  The type attribute specifies the 
media type of the image.
The x:documentation element is an Atom text construct similar to 
atom:summary.  I would have just reused atom:summary but given that the 
core spec does not expressly allow for atom:summary within atom:link, I 
felt doing so would be problematic.  The purpose of x:documentation is 
to allow an extended, human-readable description of the link to be provided.

In another direction, I've thinking about how to allow links to express 
specific information about the resource being linked so that either a) 
modifications of the resource can be detected or b) specific versions of 
the resource can be referenced.

   <link rel="enclosure" href="..."
      x:md5="{hash}"
      x:etag="{entity tag}"
      x:last-modified="{http date}" />

The values of each attribute corresponds to an equivalent HTTP header.

Lastly, a while back Eric Scheid and I discussed a bit about how 
alternate locations for a link could be expressed (e.g. mirrors).  He 
was going to write up a draft, but I'm not sure about the status of that 
effort. Here's what I'm thinking:

  <link rel=enclosure" href"..." ...>
    <x:alternate href="..." title="..." />
    <x:alternate href="..." title="..." />
  </link>

Each x:alternate identifies an alternative URL for the link resource.  
The media type, length, hreflang, etc are all expected to be the same 
for each alternate.  The x:md5.x:etag, and x:last-modified attributes 
from above could be used.

Thoughts? Gripes? Praise?

- James

---

From: "James Holderness" <[email-masked]>
Date: Sat, 22 Oct 2005 04:20:44 +0100

> sponsored links / advertisements within feeds.

Not sure about this. Why would an aggregator display such a link? At best 
you might get an option in the aggregator asking whether the user wanted to 
see sponsored links, but then you have to ask yourself how many users would 
enable such an option. As a content provider I would be inclined to just 
slap them at the bottom of the message somewhere with a little header saying 
"sponsored links". Not pretty, but at least you can be sure the links will 
be seen.

> Lastly, a while back Eric Scheid and I discussed a bit about how alternate 
> locations for a link could be expressed (e.g. mirrors).  He was going to 
> write up a draft, but I'm not sure about the status of that effort. Here's 
> what I'm thinking:
>

I like this a lot. You get fallback support when a link goes down as well as 
the ability to download from multiple sources simultaneously for extra 
speed. For this to work, though, it's vital that these resources are 
bit-for-bit identical. If not I think they MUST include an x:md5 attribute 
so an aggregator can tell which are safe to interleave.

Regards
James

---

From: James M Snell <[email-masked]>
Date: Fri, 21 Oct 2005 20:34:34 -0700

James Holderness wrote:

> James M Snell wrote:
>
>> Ok, now that a number of the other extensions I've been working on 
>> are moving along, it's time to turn my attention to a couple of other 
>> ideas I've been stewing on.  One of which is link[rel="sponsored"] to 
>> indicate sponsored links / advertisements within feeds.
>
>
> Not sure about this. Why would an aggregator display such a link? At 
> best you might get an option in the aggregator asking whether the user 
> wanted to see sponsored links, but then you have to ask yourself how 
> many users would enable such an option. As a content provider I would 
> be inclined to just slap them at the bottom of the message somewhere 
> with a little header saying "sponsored links". Not pretty, but at 
> least you can be sure the links will be seen.
>
I know, this basically comes down to a trust issue... that is, do you 
trust that aggregators and users will respect 'em.  I'm not convinced 
either, but I wanted to at least float the idea.

>> was going to write up a draft, but I'm not sure about the status of 
>> that effort. Here's what I'm thinking:
>>
> I like this a lot. You get fallback support when a link goes down as 
> well as the ability to download from multiple sources simultaneously 
> for extra speed. For this to work, though, it's vital that these 
> resources are bit-for-bit identical. If not I think they MUST include 
> an x:md5 attribute so an aggregator can tell which are safe to 
> interleave.
>
Good points.

- James

---

From: Eric Scheid <[email-masked]>
Date: Sat, 22 Oct 2005 19:15:39 +1000

> so an aggregator can tell which are safe to interleave.

that's a different direction, but an interesting one.

What we were thinking was along the lines of saying: here is enclosure in
mp3 format, but it's also available as ogg, wav, and in hreflang="fr-CA" for
you Canadian rebels.

it would be fair to say that any two x:alternate with different @href's but
equivalent x:md5 are mirrors. That can fit into the model with no other
modifications :-)

e.

---

From: James M Snell <[email-masked]>
Date: Sat, 22 Oct 2005 08:14:51 -0700

>mp3 format, but it's also available as ogg, wav, and in hreflang="fr-CA" for
The challenge with using alternate to point to files of different types 
is that why would someone do (a) when they can already do (b) without 
the help of a new extension

(a)
<link rel="enclosure" type="audio/mpeg" href="http://example.com/file.mp3">
  <x:alternate type="application/ogg" href="http://example2.com/file.ogg" />
</link>

(b)
<link rel="enclosure" type="audio/mpeg" 
href="http://example.com/file.mp3" />
<link rel="enclosure" type="application/ogg" 
href="http://example2.com/file.ogg" />

What I want is a way of indicating that a particular resource is 
available at multiple locations.  I'll use multiple link elements to 
indicate that there are multiple formats. 

>equivalent x:md5 are mirrors. That can fit into the model with no other
I would argue that the x:md5 for all alternates should be the same as 
the parent link.

- James

---

From: Eric Scheid <[email-masked]>
Date: Sun, 23 Oct 2005 03:30:04 +1000

> href="http://example2.com/file.ogg" />

With (b), how could you ever then provide multiple distinct enclosures for
an entry. With (b) you're trying to say that the two sound files are the
same thing, just different formats.

For example, I might want to provide a movie file with commentary, and
another movie file without commentary, and a third movie file showing just
the special effects part in slow motion. They are not substitutes for each
other.

With (a), we know the .mp3 and the .ogg are simply different formats of the
same thing. With (b) we don't know either way.

> indicate that there are multiple formats.

And some aggregators will treat that as a basket of different enclosures and
try downloading all of them.

> I would argue that the x:md5 for all alternates should be the same as

What about this though:

<entry xml:lang="en">
  <link href="1" rel="enclosure"
    type="audio/mpeg" x:md5="hash1" title="soundtrack">
    <x:alternate href="2" type="audio/mpeg" x:md5="hash1"/>
    <x:alternate href="3" type="audio/mpeg" x:md5="hash1"/>
    <x:alternate href="4" type="audio/mpeg" x:md5="hash1"/>
    <x:alternate href="5" type="application/ogg" x:md5="hash2"/>
    <x:alternate href="6" type="application/ogg" x:md5="hash2"/>
    <x:alternate href="7" type="application/ogg" x:md5="hash2"/>
    <x:alternate href="8" type="audio/wav"/>
  </link>
  <link href="9" rel="enclosure" type="audio/mpeg" title="commentary">
    <x:alternate href="10" type="audio/mpeg" hreflang="pt"/>
  </link>
</entry>

Here we have an entry with two enclosures. The first enclosure is the
soundtrack, and is available in mp3 from one primary URI and three mirrors,
and also available in .ogg from three mirrors, and for the truly desperate
also available as a .wav file. The second enclosure is a commentary sound
track, but not available in any other formats or from any other mirrors, but
there is a Portuguese translation variant if you (really) want.

e.

---

From: "James Holderness" <[email-masked]>
Date: Mon, 24 Oct 2005 12:18:56 +0100

Eric Scheid wrote:
>> href="http://example.com/file.mp3">

I like (a) in concept because, as you say, it enables you to tell when two 
links are the same so if you're auto-downloading you don't need them both. 
However, I do think James is right in thinking that many people will just 
use (b) because it's already there.

I don't see the harm in allowing (a) though. If a feed producer uses (a) and 
an end-user has auto-downloading enabled for that feed, they both benefit 
from less wasted bandwidth. The only downside would be that aggregators that 
aren't aware of this extension would fail to see the alternate enclosures. 
Is that so bad though? It's a trade-off the feed producer has to make - I'm 
not sure we should be making that decision for them.

Something else that just occured to me: is there any likelyhood of this kind 
of extension breaking existing aggregators? I know that technically there's 
nothing wrong with it, but I can see aggregators that have home-grown XML 
parsers possibly getting confused by this.

I'm not suggesting the proposal should be abandoned because of a few poor 
implementations of the Atom spec, but I think it would be worth finding out 
how much of a problem it is (if anything). Maybe run a test feed through a 
few of the most popular aggregators and see how many explode.

The ones I've tested so far: neither FeedReader nor FeedDemon support 
enclosures. I'm not sure if that's good news or bad news.

Regards
James

---

From: Antone Roundy <[email-masked]>
Date: Mon, 24 Oct 2005 10:03:05 -0600

On Oct 24, 2005, at 5:18 AM, James Holderness wrote:
> I like (a) in concept because, as you say, it enables you to tell  
> when two links are the same so if you're auto-downloading you don't  
> need them both. However, I do think James is right in thinking that  
> many people will just use (b) because it's already there.
>
> I don't see the harm in allowing (a) though. If a feed producer  
> uses (a) and an end-user has auto-downloading enabled for that  
> feed, they both benefit from less wasted bandwidth. The only  
> downside would be that aggregators that aren't aware of this  
> extension would fail to see the alternate enclosures. Is that so  
> bad though? It's a trade-off the feed producer has to make - I'm  

Here's the middle path:

(c)
<link rel="enclosure" type="audio/mpeg" href="http://example.com/ 
file.mp3" x:link-set="a" />
<link rel="enclosure" type="application/ogg" href="http:// 
example2.com/file.ogg" x:link-set="a" />

This won't save you from bandwidth waste by aggregators that don't  
support the extension, but it also won't prevent users of those  
aggregators from getting the data in a format they can use.  That  
said, this is not my preferred method.  I'd rather protect bandwidth  
and the user's hard drive space--all the more important because  
enclosures are often quite large.

Here's a final option--is it legal?  Is it better or worse than (a)  
in any ways?

(d)
<link rel="enclosure" type="audio/mpeg" href="http://example.com/ 
file.mp3">
     <link rel="alternate" type="application/ogg" href="http:// 
example2.com/file.ogg" />
</link>

Better: Doesn't require processing of a new namespace or element-- 
just a new way of using the data that one gets out of an existing  
element.

I prefer d, a, c and then b.

---

From: "James Holderness" <[email-masked]>
Date: Mon, 24 Oct 2005 18:43:23 +0100

Antone Roundy wrote:
> Here's a final option--is it legal?  Is it better or worse than (a)  in 
> any ways?
>
> (d)

I'm not completely sure yet, but  I'm quite partial to this approach.

My only suggestion would be using rel="enclosure" on the inner links rather 
than "alternate". There will be some Atom processors [1] that won't be able 
to tell the difference between an inner link and an outer link. If they're 
both marked as enclosures it won't really matter (you lose the benefits, but 
no worse than normal). However, interpreting the inner link as an 
"alternate" to the atom entry could be bad.

If you combine this with the requirement that an inner link with the same 
type and hreflang as the outer link must be bit-for-bit identical, we could 
cover the other use-case of multiple download sources. So far, no new 
elements or attributes necessary. Not sure about the legality.

Regards
James

[1] http://philringnalda.com/blog/2005/06/ms_embraces_rss.php

---

From: James M Snell <[email-masked]>
Date: Mon, 24 Oct 2005 10:57:24 -0700

The concept of reusing atom namespaced elements as extensions inside 
other atom namespaced elements has come up before and has generally been 
frowned upon. 

James Holderness wrote:

> My only suggestion would be using rel="enclosure" on the inner links 
> rather than "alternate". There will be some Atom processors [1] that 
> won't be able to tell the difference between an inner link and an 
> outer link. If they're both marked as enclosures it won't really 
> matter (you lose the benefits, but no worse than normal). However, 
> interpreting the inner link as an "alternate" to the atom entry could 
> be bad.
>
> If you combine this with the requirement that an inner link with the 
> same type and hreflang as the outer link must be bit-for-bit 
> identical, we could cover the other use-case of multiple download 
> sources. So far, no new elements or attributes necessary. Not sure 
> about the legality.
>
> Regards
> James
>

---

From: "James Holderness" <[email-masked]>
Date: Mon, 24 Oct 2005 19:04:46 +0100

> other atom namespaced elements has come up before and has generally been 

No big deal. I'm quite happy with your initial x:alternate proposal.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Mon, 24 Oct 2005 21:48:16 +0200

> example2.com/file.ogg" />

I have a completely different proposition.

(e)
<link
    rel="enclosure" type="audio/mpeg"
    href="http://example.com/file.mp3"
    encl:mirrors="http://www2.example.com/file.mp3 http://www3.example.com/file.mp3"
    xml:id="x-file"
    />
<link
    rel="alternative-enclosure" type="application/ogg"
    href="http://example2.com/file.ogg"
    encl:alternative-to="x-file"
    />

Since bit-for-bit identical files all have the exact same
attributes, there is absolutely no reason to have an entire tag
dedicated to each. In addition, making mirror URLs second-class
citizens in this ways provides an intuitive hint at the
bit-for-bit identity semantics.

Specifying alternative formats with a distinct link relationship
prevents bandwidth and diskspace drain from oblivious clients.

And once you’ve gotten so far as to think of one enclosure as the
preferentially advertised format, it’s no stretch to think of
grouping alternative-format enclosures as linking the alternative
format enclosures to the preferrentially advertised one. And
that’s a purpose for which IDs work just fine.

Thinking in terms of code I believe this model is a bit easier to
process than any of the alternatives. A list of mirror URLs is
obviously trivial to retrieve. And just as you can do with the
nested-element models, you can read the list of enclosure groups
right off the markup simply by looking for any `enclosure` links.
But less nesting is easier to process.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: Antone Roundy <[email-masked]>
Date: Mon, 24 Oct 2005 14:24:29 -0600

> bit-for-bit identity semantics.
Interesting.  Filling an attribute with a list of URIs doesn't really  
appeal to me though.  How about this:

<link rel="enclosure" type="audio/mpeg" href="http://example.com/ 
file.mp3" xml:id="x-file">
     <altlink:mirror href="http://www2.example.com/file.mp3" />
     <altlink:mirror href="http://www3.example.com/file.mp3" />
</link>

> prevents bandwidth and diskspace drain from oblivious clients.
Sounds good, but you may have noticed above that I used a prefix not  
specific to enclosures--there's no reason to tie this all to one  
particular type of link (nor to make it look as if it were tied to  
one specific link type).  So the other link might, for example, be:

<link rel="alternative-link" type="application/ogg" href="http:// 
example2.com/file.ogg" altlink:primary="x-file" />

Although "alternative-link" doesn't tell you what kind of link this  
is, since you're going to have to tie it back to the primary link to  
decide what to do with it anyway, it really shouldn't matter.  Note  
that I changed "alternative-to" to "primary" just because it's  
shorter and one word.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Mon, 24 Oct 2005 22:59:32 +0200

* Antone Roundy <[email-masked]> [2005-10-24 22:35]:
> Interesting. Filling an attribute with a list of URIs doesn't
> really appeal to me though. How about this:
> 

It’s a lot more verbose and you have to fiddle with nesting.

What do you get in return? “It looks more XMLish”?

> Sounds good, but you may have noticed above that I used a
> prefix not specific to enclosures--there's no reason to tie
> this all to one particular type of link (nor to make it look
> as if it were tied to one specific link type). So the other
> link might, for example, be:

I don’t know if striving for generality in this fashion without
a practical need is worthwhile. It smells of architecture
astronautics for a reason I can’t particularly pinpoint. So maybe
my instinct is wrong.

> Note that I changed "alternative-to" to "primary" just because
> it's shorter and one word.

Works for me.

Regards,

---

From: "James Holderness" <[email-masked]>
Date: Mon, 24 Oct 2005 22:51:12 +0100

Antone Roundy wrote:
> appeal to me though.

Me neither. Something feels wrong about that. If you want a concrete reason, 
it requires extra parsing whereas everything else would be automatically 
parsed by the XML library.

>     <altlink:mirror href="http://www3.example.com/file.mp3" />

Isn't this essentially the same as James' original proposal?

Regards
James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 25 Oct 2005 00:13:02 +0200

* James Holderness <[email-masked]> [2005-10-25 00:00]:
> If you want a concrete reason, it requires extra parsing
> whereas everything else would be automatically parsed by the
> XML library.

You have to split on whitespace; that’s much easier in my book
than finding a nodeset of nested elements and iterating over it.

> Isn't this essentially the same as James' original proposal?

Yes.

Regards,

---

From: Antone Roundy <[email-masked]>
Date: Mon, 24 Oct 2005 16:28:29 -0600

> What do you get in return? “It looks more XMLish”?
1) Easier parsing, as James said, since your XML parsing library is  
going to give you the data with the URI's already split apart.

2) You can break lines between elements, but you can't inside an  
attribute, so it's better for display for humans.

I think XMLishness leans this direction for good reason.

> astronautics for a reason I can’t particularly pinpoint. So maybe
The way I see it, striving for specificity without a practical need  
isn't worthwhile.  Unless generalizing risks leading to some sort of  
problem, why do it?  I see no potential problems.

What if someday somebody does come up with a non-enclosure use for  
this (which hardly seems far-fetched to me--enclosures aren't the  
only things that get mirrored or exist in multiple formats)?  They'll  
have to define a new mechanism for it which is either going to be  
identical except for element names, or they're going to invent  
another way to do the same thing.  Either way, the pain of supporting  
both is completely unnecessary unless there's potential for  
generality causing problems.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 25 Oct 2005 10:07:49 +1000

On 25/10/05 3:43 AM, "James Holderness" <[email-masked]> wrote:

> to tell the difference between an inner link and an outer link.

and we're back to the duplicate bandwidth problem again :-(

> elements or attributes necessary.

what about the use case of alternate formats (etc) for the same resource?

> Not sure about the legality.

not legal, since atom:link cannot appear there ie. while atom:link (the
container) can contain foreign markup, atom:link (the embedded) is not
foreign markup.

e.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 25 Oct 2005 10:14:25 +1000

On 25/10/05 8:13 AM, "A. Pagaltzis" <[email-masked]> wrote:

> You have to split on whitespace; that¹s much easier in my book

I recall people screaming about "micro-parsers" before for a different
attribute. Has anything changed?

e.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 25 Oct 2005 12:39:59 +1000

>   encl:alternative-to="x-file"

-1 ... this is starting to get ugly.

e.

---

From: James M Snell <[email-masked]>
Date: Mon, 24 Oct 2005 20:12:31 -0700

>-1 ... this is starting to get ugly.
+1 to Eric's -1.  Let's keep it simple.

<link rel="..." type="..." href="...">
  <x:alternate type="..." href="..." title="..." />
</link>

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 25 Oct 2005 05:59:23 +0200

* Antone Roundy <[email-masked]> [2005-10-25 00:35]:
> 2) You can break lines between elements, but you can't inside
> an attribute, so it's better for display for humans.

That’s not what the XML spec says.

> What if someday somebody does come up with a non-enclosure use
> for this (which hardly seems far-fetched to me--enclosures
> aren't the only things that get mirrored or exist in multiple
> formats)? They'll have to define a new mechanism for it which
> is either going to be identical except for element names, or
> they're going to invent another way to do the same thing.
> Either way, the pain of supporting both is completely
> unnecessary unless there's potential for generality causing
> problems.

If it isn’t obvious from the start what it means that there’s
an alternative-link for a via link or a previous or next link,
then clients will have to support each of these use case
separately. So on the implementor’s end, there’s no discernible
difference between the pain of supporting either approach.

Regards,

---

From: Antone Roundy <[email-masked]>
Date: Mon, 24 Oct 2005 22:21:11 -0600

> That’s not what the XML spec says.

Doh!  Who knows where I got that idea.  I still prefer to have each  
piece of data in it's own place.

> difference between the pain of supporting either approach.

I'm not sure I understand what you're saying.  Are you saying that  
one might do this if they want and alternate of a "next" link?

<link rel="next" xml:id="foo" ... />
<link rel="alternate-enclosure" x:alternate-of="foo" ... />

If that's what you mean, then sure, the code for that would be the  
same as for:

<link rel="next" xml:id="foo" ... />
<link rel="alternate-link" x:alternate-of="foo" ... />

...but it would sure look odd.  I see no advantage to naming these  
things in terms of enclosures.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 25 Oct 2005 14:24:41 +1000

> <x:alternate type="..." href="..." title="..." />

I'm also liking it from another angle...

With some of the other approaches dumb clients do harm to others, and while
smart clients do no harm they don't get anything which dumb clients already
get.

With this approach dumb clients do no harm, and smart clients gain benefits
not available to dumb clients. It sets up the right ecological pressures for
the market to evolve in a way which is beneficial.

So while "let the market/implementations decide" is often persuasive, we
really should at the same time be asking what environment/ecology are we
establishing for this evolution.

e.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 25 Oct 2005 14:31:05 +1000

There's another problem with this:

>   @encl:mirrors="http://www2.example.com/file.mp3
>        http://www3.example.com/file.mp3"

... how do you attach @title to each URI,

for example @title="Blah blah -- European Mirror".

e.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 25 Oct 2005 08:59:17 +0200

* Antone Roundy <[email-masked]> [2005-10-25 06:30]:
> I'm not sure I understand what you're saying. Are you saying
> that one might do this if they want and alternate of a "next"
> link?
> 

No, not at all.

> If that's what you mean, then sure, the code for that would be
> the same as for:
> 
> ...but it would sure look odd. I see no advantage to naming
> these things in terms of enclosures.

I am asking if is there a generic way for an application to
implement alternate-link processing that gives sensible behaviour
for any type of main link. If an implementor has to support
alternative links explicitly for each type of main link, where’s
the difference to having specific relationships for alternative
links depending on the main link type?

Regards,

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 25 Oct 2005 09:06:46 +0200

> for example @title="Blah blah -- European Mirror".

You can’t. My assumption was that supplying divergent metadata
for what are supposed to be bit-for-bit copies of a file is not
particularly useful, whereas having no such option serves as a
hint that the copies are not to be considered as independent
entities.

Is providing a @title an option that a lot of people would use
and/or someone out there cannot do without?

Regards,

---

From: Henry Story <[email-masked]>
Date: Tue, 25 Oct 2005 09:17:05 +0200

On 24 Oct 2005, at 22:59, A. Pagaltzis wrote:

>> really appeal to me though.

+1000000 (me and all my co-voting cats)

>> How about this:

yes!? We are using xml!

> astronautics for a reason I can’t particularly pinpoint. So maybe

maybe :-)
A million cats can't be wrong.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 25 Oct 2005 17:31:38 +1000

On 25/10/05 4:59 PM, "A. Pagaltzis" <[email-masked]> wrote:

> for any type of main link.

<link ..>
    <x:alternate ...>
</link>

couldn't get more generic than that.

read it as: here is a link (ooh, look, some alternate href's!)

> If an implementor has to support alternative links explicitly for each type of
> main link, where¹s the difference to having specific relationships for
> alternative links depending on the main link type?
> 
good point.

e.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 25 Oct 2005 17:36:34 +1000

On 25/10/05 5:17 PM, "Henry Story" <[email-masked]> wrote:

>> It¹s a lot more verbose and you have to fiddle with nesting.
>> 
>> What do you get in return? ³It looks more XMLish²?
>> 
> 
> yes!? We are using xml!

not only that, but if someone wants to write another extension (gasp!), it
would be very easy to fold it in, using native XML methods...

<link ..>
    <x:alternate y:attribute=".." ...>
        <z:extension .../>
    </s:alternate>
</link>

(not that I can think of any such extensions, but why be a bastard to future
inventors and innovators?)

e.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 25 Oct 2005 17:37:20 +1000

> and/or someone out there cannot do without?

In Atom 1.0 .... not enough deployment to say

In HTML ... *lots* of current practice of labelling mirrors with the org
name and/or location. Lots.

e.

---

From: Antone Roundy <[email-masked]>
Date: Tue, 25 Oct 2005 09:32:44 -0600

> links depending on the main link type?

Here are a few examples of generic processing algorithms an  
application might use:

Mirrors:
1) Randomly selecting a mirror to download from, thus helping to  
spread the bandwidth usage among them.
2) Try the main link, and if the DNS lookup fails, or a connection  
can't be made or something, automatically try the next one.
3) Ping each of the servers in the background, and if the user clicks  
the link, use the fastest one.

Alternates:
1) Have a prioritized list of formats, and choose the link that  
points to the highest priority format.
2) Of all the formats the app supports, choose the one with the  
smallest @length, if present.

Either one:
1) Show some sort of UI for selecting which link to follow (perhaps  
have the main link selected by default, but allow the user to select  
an alternate from the popup).

None of those ideas is necessarily tied to any particular link  
relation.  They might be more important for enclosures than any of  
the other relations that have been defined so far, and an application  
may or may not do some for enclosures that it doesn't do for some  
other specific link relations.  But again, it comes back to the yet  
unanswered question, are there any disadvantages to keeping it  
generic?  I haven't heard anyone suggest any downside yet--only that  
some people can't imagine why anyone would want to use alternative  
links for anything but enclosures.

---

From: James M Snell <[email-masked]>
Date: Tue, 25 Oct 2005 10:04:28 -0700

Hmmm...

> Mirrors:
<link rel="..." href="..." type="...">
  <x:mirror href="..." title="..." />
</link>

> Alternates:
<link rel="..." href="..." type="..." x:group="alternate-group" />
<link rel="..." href="..." type="..." x:group="alternate-group" />

All-in-one example

The x:group attribute links the two alternates into a single grouping; 
the x:mirror specifies the mirrors for each link.  nf:follow="no" is my 
Atom Link No Follow extension that tells clients not to automatically 
download the enclosure.  Dumb clients will see what amounts to the 
current status quo, two different enclosures of different types.  Smart 
clients will see the mirrors, the grouping and the no-follow instruction.

<link rel="enclosure" href="http://example.com/softwarepackage.zip" 
type="application/zip" x:group="software-package" nf:follow="no">
  <x:mirror href="http://example2.com/softwarepackage.zip" 
title="California Server" />
  <x:mirror href="http://example3.com/softwarepackage.zip" 
title="European Server" />
</link>
<link rel="enclosure" href="http://example.com/softwarepackage.tar.gz" 
type="application/x-gzip" x:group="software-package" nf:follow="no">
  <x:mirror href="http://example2.com/softwarepackage.tar.gz" 
title="California Server" />
  <x:mirror href="http://example3.com/softwarepackage.tar.gz" 
title="European Server" />
</link>

Thoughts?

- James

---

From: Antone Roundy <[email-masked]>
Date: Tue, 25 Oct 2005 12:18:29 -0600

On Oct 25, 2005, at 11:04 AM, James M Snell wrote:
> All-in-one example
>
> The x:group attribute links the two alternates into a single  
> grouping; the x:mirror specifies the mirrors for each link.   
> nf:follow="no" is my Atom Link No Follow extension that tells  
> clients not to automatically download the enclosure.  Dumb clients  
> will see what amounts to the current status quo, two different  
> enclosures of different types.  Smart clients will see the mirrors,  
> the grouping and the no-follow instruction.
>
> <link rel="enclosure" href="http://example.com/ 
> softwarepackage.tar.gz" type="application/x-gzip" x:group="software- 
> package" nf:follow="no">

The only thing I would change is the name of x:mirror/@title to make  
it clear that it isn't intended(?) to replace the parent link's  
@title.  My current favorite name is "label".

---

From: "James Holderness" <[email-masked]>
Date: Tue, 25 Oct 2005 19:45:49 +0100

James M Snell wrote:
>  <x:mirror href="http://example3.com/softwarepackage.zip" title="European 
> Server" />
> </link>

I'm not quite clear how the nofollow attribute is supposed to work here. If 
a feed producer wants to allow automatic downloads, but is providing the 
file in multiple formats (only one of which is needed) how should that be 
expressed? As you have it at the moment, the client can't auto-download at 
all. Should he just leave nofollow off and rely on the client to download 
only one?

Also, assuming the title on the main link is supposed to describe the 
download file itself, there appears to be no way to inform the user of the 
mirror location of the main URI. Without a location name of some sort, the 
user can't make an informed decision about which mirror would be best to 
use. Perhaps something along the line of Antone's "label" suggestion might 
help here.

Regards
James

---

From: James M Snell <[email-masked]>
Date: Tue, 25 Oct 2005 12:16:36 -0700

James Holderness wrote:

>> <link rel="enclosure" 
>> href="http://example.com/softwarepackage.tar.gz" 
> I'm not quite clear how the nofollow attribute is supposed to work 
> here. If a feed producer wants to allow automatic downloads, but is 
> providing the file in multiple formats (only one of which is needed) 
> how should that be expressed? As you have it at the moment, the client 
> can't auto-download at all. Should he just leave nofollow off and rely 
> on the client to download only one?
>
In this particular example yes.  The idea was to demonstrate that there 
are means by which smart client behavior can be controlled given the 
concerns about potential bandwidth abuse.  Dumb clients continue to act 
the way they would today.

> download file itself, there appears to be no way to inform the user of 
> the mirror location of the main URI. Without a location name of some 
> sort, the user can't make an informed decision about which mirror 
> would be best to use. Perhaps something along the line of Antone's 
> "label" suggestion might help here.
>
I could just do this:

<link rel="enclosure" href="http://example.com/softwarepackage.tar.gz" 
type="application/x-gzip" x:group="software-package" nf:follow="no" >
 <x:mirror href="http://example.com/softwarepackage.tar.gz" label="Main 
Server" />
 <x:mirror href="http://example2.com/softwarepackage.tar.gz" 
label="California Server" />
 <x:mirror href="http://example3.com/softwarepackage.tar.gz" 
label="European Server" />
</link>

- James

---

From: Antone Roundy <[email-masked]>
Date: Tue, 25 Oct 2005 13:26:41 -0600

On Oct 25, 2005, at 1:16 PM, James M Snell wrote:
>> Also, assuming the title on the main link is supposed to describe  
>> the download file itself, there appears to be no way to inform the  
>> user of the mirror location of the main URI. Without a location  
>> name of some sort, the user can't make an informed decision about  
>> which mirror would be best to use. Perhaps something along the  
>> line of Antone's "label" suggestion might help here.
>>
>>
> I could just do this:
>
> package" nf:follow="no" >
> <x:mirror href="http://example.com/softwarepackage.tar.gz"  
> label="Main Server" />
or this:

<link rel="enclosure" href="http://example.com/ 
softwarepackage.tar.gz" type="application/x-gzip" x:group="software- 
package" x:label="Main Server" nf:follow="no" >
<x:mirror href="http://example2.com/softwarepackage.tar.gz"  
x:label="California Server" />
<x:mirror href="http://example3.com/softwarepackage.tar.gz"  
x:label="European Server" />
</link>

---

From: Eric Scheid <[email-masked]>
Date: Wed, 26 Oct 2005 10:50:06 +1000

> @title.  My current favorite name is "label".

+1