Subject: Feeds MUST have alternate links?

From: Norman Walsh <[email-masked]>
Date: Wed, 25 Aug 2004 08:03:20 -0400

The 01 draft says:

  4.2.2  "atom:link" Element

    The "atom:link" element is a Link construct that conveys a URI
    associated with the feed.  The nature of the relationship as well as
    the link itself is determined by the element's content.

    atom:head elements MUST contain at least one atom:link element with a
    rel attribute value of "alternate".

Why must I produce an alternate representation of the feed?

I have a practical reason for asking. Someone asked me to produce a
feed for all the photographs on norman.walsh.name. I can do that, but
I'm not going to produce an HTML page that is an alternate
representation of that feed. I suppose I could, but I'd rather not and
I don't see why I should.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | When dealing with the insane, the best
http://nwalsh.com/            | method is to pretend to be
                              | sane.--Hermann Hesse

---

From: Mark Pilgrim <[email-masked]>
Date: Wed, 25 Aug 2004 09:13:51 -0400

> I don't see why I should.

I think http://norman.walsh.name/topics#Photography would suffice as
an alternate link for that feed.

-- 
Cheers,
-Mark

---

From: Tim Bray <[email-masked]>
Date: Wed, 25 Aug 2004 06:59:59 -0700

> Why must I produce an alternate representation of the feed?

Practically speaking, in NetNewsWire, I can click on any of the feeds 
in my subscription list, and it usually sends my browser somewhere 
sensible, normally the front page of the blog or news service or 
whatever that I'm subscribed to.  Clearly in some cases, figuring what 
best to put there can involve a judgement call.  -Tim

---

From: Norman Walsh <[email-masked]>
Date: Wed, 25 Aug 2004 10:28:04 -0400

/ Mark Pilgrim <[email-masked]> was heard to say:
| I think http://norman.walsh.name/topics#Photography would suffice as
| an alternate link for that feed.

Yeah. I suppose. I guess I was thinking too literally.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | The stone fell on the pitcher? Woe to
http://nwalsh.com/            | the pitcher. The pitcher fell on the
                              | stone? Woe to the pitcher.--Rabbinic
                              | Saying

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 26 Aug 2004 08:03:30 +0200

> Why must I produce an alternate representation of the feed?

I would like to repeat that question. I have no answer for it, at least. I  
will use Atom in _many_ scenarios where there aren't any alternative  
representation for either the feed or the entries. Why should I have to  
create an HTML page no one on the planet will request just to accomodate  
the specification?

> I don't see why I should.

+1.

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Sam Ruby <[email-masked]>
Date: Thu, 26 Aug 2004 06:37:40 -0400

Asbjørn Ulsberg wrote:
> I would like to repeat that question. I have no answer for it, at least. 
> I  will use Atom in _many_ scenarios where there aren't any alternative  
> create an HTML page no one on the planet will request just to 
> accomodate  the specification?
> 

Let me point out that the channel link element is required in every 
version of RSS from 0.91 to 1.0 to 2.0.

And as a co-author of the feedvalidator, I have seen a lot of broken 
feeds where people have either inadvertently or deliberately ignored the 
specification, but I don't recall ever seeing one where this element was 
not present.

http://my.netscape.com/publish/formats/rss-spec-0.91.html#channel
http://web.resource.org/rss/1.0/spec#s5.3
http://blogs.law.harvard.edu/tech/rss#requiredChannelElements
http://feedvalidator.org/docs/error/MissingLink.html

- Sam Ruby

---

From: Mark Pilgrim <[email-masked]>
Date: Thu, 26 Aug 2004 10:23:59 -0400

> version of RSS from 0.91 to 1.0 to 2.0.

Correction: it was also required in RSS 0.90.

http://www.purplepages.ie/RSS/netscape/rss0.90.html

-- 
Cheers,
-Mark

---

From: Danny Ayers <[email-masked]>
Date: Thu, 26 Aug 2004 16:34:07 +0200

> > On Wed, 25 Aug 2004 08:03:20 -0400, Norman Walsh <[email-masked]> wrote:
Why should I have to
> > accomodate  the specification?

Without considerably more justification, that gets my +1 too.

> version of RSS from 0.91 to 1.0 to 2.0.

Mark kindly supplied the perfect response to this a few weeks ago:

http://www.rider.edu/~suler/zenstory/ritualcat.html

Cheers,
Danny.

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 26 Aug 2004 07:57:35 -0700 (PDT)

--- Sam Ruby <[email-masked]> wrote:

> > >> I'm not going to produce an HTML page that is
an
> alternate

The feedvalidator is primarily used for validating of
websites. However many have claimed that Atom will be
more than a site syndication format. For example, I'm
in the process of adding NNTP support to RSS Bandit. I
will archive USENET groups and RSS feeds in the same
format. If I choose Atom as this format what would you
suggest I use as the alternate link for the feed for
microsoft.public.dotnet.xml? 

Would 'news:microsoft.public.dotnet.xml' be an
acceptable <link rel="alternate" /> value? 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #25
No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot.

__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

---

From: Tim Bray <[email-masked]>
Date: Thu, 26 Aug 2004 09:31:44 -0700

On Aug 26, 2004, at 7:57 AM, Dare Obasanjo wrote:

> For example, I'm

Sounds plausible.  Another possibility would be 
http://groups.google.com/groups?group=microsoft.public.dotnet.xml, er, 
well, the MSDN equivalent I guess :) -Tim

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 26 Aug 2004 09:34:44 -0700 (PDT)

--- Tim Bray <[email-masked]> wrote:
>
> If I choose Atom as this format what would
> you
http://groups.google.com/groups?group=microsoft.public.dotnet.xml,
> er, 

Except neither of these indexes all news groups
[especially not newsgroups within an intranet]. So
that link would 404 at unexpected times. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #23
I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks.

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 27 Aug 2004 08:48:20 +0200

> version of RSS from 0.91 to 1.0 to 2.0.

...Which is exactly why I (and others I know of) can't use RSS for many of  
the purposes I'd like, but instead hope to be able to use Atom in those  
areas.

Many Atom entries and feeds won't have alternate, human readable  
(typically HTML) alternatives. Atom is in such cases used more like a  
transport layer of arbitrary resources.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 27 Aug 2004 08:48:20 +0200

---

From: Mark Pilgrim <[email-masked]>
Date: Fri, 27 Aug 2004 09:18:13 -0400

On Fri, 27 Aug 2004 08:48:20 +0200, Asbjørn Ulsberg
<[email-masked]> wrote:
> ....Which is exactly why I (and others I know of) can't use RSS for many of

If you're looking for a syndication format that's even looser and has
even fewer required elements than RSS, you're in the wrong place.

> (typically HTML) alternatives.

If by "many" you mean "vanishingly few", then yes.  Otherwise, no.

-- 
Cheers,
-Mark

---

From: Ian Davis <[email-masked]>
Date: Fri, 27 Aug 2004 14:45:42 +0100

> If by "many" you mean "vanishingly few", then yes.  Otherwise, no.
What do you suggest feeds like the following should do?

http://offog.org/changes.rss

Ian

---

From: Antone Roundy <[email-masked]>
Date: Fri, 27 Aug 2004 09:54:35 -0600

> even fewer required elements than RSS, you're in the wrong place.
While I'm all for requirements that prevent problems, I'm still 
wondering what problems or difficulties will arise if some entries 
don't have links.  Anyone?

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 27 Aug 2004 18:25:51 +0200

> even fewer required elements than RSS, you're in the wrong place.

No, that's not what I'm looking for. I just can't get the point in  
requiring an alternative representation for all Atom documents. I'll  
repeat Antone's question: «I'm still wondering what problems or  
difficulties will arise if some entries don't have links».

---

From: Toru Marumoto <[email-masked]>
Date: Sat, 28 Aug 2004 02:53:14 +0900

Asbjorn Ulsberg <[email-masked]> wrote:
>repeat Antone's question: I'm still wondering what problems or  
>difficulties will arise if some entries don't have links.
>

imho, the whole point of syndication format is to let subscriber know that a new content is up online... not to deliver itself.
Well, OK. Atom can be a content delivery format as well...

But, downside is that some simple aggregators (tickers or desktop sidebars) do not show <content>. You are supporsed to click on the title to see the acutural content on the web in a web browser. I 
know at least 5 of that kind of aggregators.

But also,if atom entries do not require alternative representations, atom might open up new posibilities..  I don't know.

Toru Marumoto
     see you on the web!

__________________________________________________
GANBARE! NIPPON!
Yahoo! JAPAN JOC OFFICIAL INTERNET PORTAL SITE
http://mail.ganbare-nippon.yahoo.co.jp/

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 27 Aug 2004 19:59:01 +0200

On Sat, 28 Aug 2004 02:53:14 +0900, Toru Marumoto <[email-masked]>  
wrote:

> imho, the whole point of syndication format is to let subscriber know  
> that a new content is up online... not to deliver itself.

That was the point of RSS, yes. I think and hope Atom will give a bit more  
than RSS to users and implementors.

> Well, OK. Atom can be a content delivery format as well...

Indeed.

> But, downside is that some simple aggregators (tickers or desktop  
> sidebars) do not show <content>. You are supporsed to click on the title  
> to see the acutural content on the web in a web browser.

If they break without <link>, can't they just don't show entries without  
one, then:

   [Untested PHP5 pseudo code]

   foreach ($feed->entry as $entry) {
     if (isset($entry->link[0])) {
       // Display the entry
     }
   }

   [Untested XSLT pseudo code]

   <xsl:template match="atom:feed">
     <xsl:apply-templates select="atom:entry[atom:link]" />
   </xsl:template>

   <xsl:template match="atom:entry">
     <!-- Display the entry -->
   </xsl:template>

   [Untested C# pseudo code]

   foreach (XmlElement entry in feed.ChildNodes) {
     if (entry.SelectSingleNode("//atom:link") != null) {
       // Display the entry
     }
   }

This check is really simple. I really can't understand the big problem  
about optional links. I do see problems with required links, though.

> But also,if atom entries do not require alternative representations,  
> atom might open up new posibilities..

Exactly.

---

From: Antone Roundy <[email-masked]>
Date: Fri, 27 Aug 2004 12:04:50 -0600

On Friday, August 27, 2004, at 11:53  AM, Toru Marumoto wrote:
>> I'm still wondering what problems or
I've heard enough people complain about feeds that have only summaries 
rather than full content to think that Atom has a life as a content 
delivery format.

> sidebars) do not show <content>. You are supporsed to click on the 
> title to see the acutural content on the web in a web browser. I know 
> at least 5 of that kind of aggregators.
Okay, that could be an issue.  A few thoughts on mitigating problems:

1) If the end user is subscribing to the feed where the entries 
originate, they can unsubscribe to feeds that don't include links in 
their entries.
2) If a service is aggregating feeds to serve to people using such an 
application (the software vendor also serves content), they can omit 
such feeds.
3) The application itself (or the aggregation service) could omit any 
items that don't have links (or could at least have an option to--it's 
possible that people might be interested in reading the headlines even 
if they can't get directly to a bigger story--like the news ticker at 
the bottom of the TV screen on CNN).

---

From: Sam Ruby <[email-masked]>
Date: Fri, 27 Aug 2004 14:41:14 -0400

>> atom might open up new posibilities..

Before anybody spends much time on creating a Pace, just be aware that 
this particular secretary will be very reluctant to schedule discussions 
around topics that are out of scope until or unless the charter is 
revised to include the topic in question.

The reason for this is quite simple: we are having a hard enough time 
staying on track for things that are in scope without dealing with 
explorations of new possible applications.

I direct everybody interested in pursuing this to read the first 
sentence of the charter and try to come up with meaningful examples of 
web resources for which Universal Resource Identifiers can not be provided.

- Sam Ruby

---

From: "Bob Wyman" <[email-masked]>
Date: Fri, 27 Aug 2004 14:45:26 -0400

Dare Obasanjo wrote:
> I'm in the process of adding NNTP support to RSS Bandit.

	Our NNTP support at PubSub.com needs a good bit of work... However,
below you'll find a sample of what we're currently doing. I would be very
happy to work with folk on defining the "proper" representation of an NNTP
item in an Atom feed. (what do we do with all the extra headers? What do we
do with "To", "From", etc?)

  <entry>
   <title><![CDATA[ Re: C#.NET vs VB.NET  ]]> </title>
   <ps:source-feed>
     <title><![CDATA[ hr.comp.programiranje.dotnet  ]]></title>
      <link rel="alternate" type="text/html"
        href="news:hr.comp.programiranje.dotnet" /> 
      <link rel="alternate" type="text/xml"
        href="news:hr.comp.programiranje.dotnet" /> 
   </ps:source-feed>
   <link rel="alternate" type="text/html"
        href="news:<[email-masked]>" /> 
   <modified>2004-08-10T05:01:43-04:00</modified> 
   <issued>2004-08-10T05:01:43-04:00</issued> 
   <id><[email-masked]></id> 
   <content type="text/html" mode="escaped">
... 
   </content>
  </entry>

		bob wyman

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 27 Aug 2004 21:19:12 +0200

> revised to include the topic in question.

That's understood.

> web resources for which Universal Resource Identifiers can not be  

The problem isn't providing URI's, but that they are supposed to be  
_alternate_ representations of the feed or entries. Is the URI of the feed  
you're looking at a good «alternate» URI for the feed? I think not, since  
it's not alternate, but instead some notion of «me» or «this».

For Atom entries, the situation is a bit different, since in many cases it  
would be useful to only use Atom feeds as transport loads and not have the  
entries represent anything else but themselves. That is, the entries  
inside a feed are first-class resources with no alternate representations.

Of course, all entries might be pulled out and placed on each own's URI  
location, but that creates the same «alternate» problem as with feeds. If  
the resource you refer to from the entry is infact the exact same resource  
you're looking at, the referred resource isn't an alternate  
representation. It's _the_ representation.

If the specification only required an atom:link element without specifying  
the values of @type or @rel, it would be better, but I still think  
atom:link should be optional alltogether, at least for atom:entry.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 28 Aug 2004 11:06:12 +0200

>even fewer required elements than RSS, you're in the wrong place.

It is

  http://www.google.com/search?q=intitle%3A%22untitled+document%22
  http://www.google.com/search?q=intitle%3A%22Welcome+to+Adobe+GoLive%22

http://www.google.com/search?q=intitle%3A%22Willkommen+bei+Adobe+GoLive%22
  ...

pointless to require presence of meta data that is not required for
interoperability, and making meta data up just to satisfy obscure
requirements in a specification actually reduces the value of the
meta data when used properly. For the examples above it seems obvious
that it would have been better to omit the <title> element and allow
implementations to determine a title from the content of the document,
<h1> elements for example.

---

From: Mark Pilgrim <[email-masked]>
Date: Sat, 28 Aug 2004 18:26:09 -0400

On Sat, 28 Aug 2004 11:06:12 +0200, Bjoern Hoehrmann <[email-masked]> wrote:
> meta data when used properly.

That won't help you make your case at all.  Channel title has been
required in every version of RSS since 1999, and in CDF before that. 
Are there thousands of "Untitled blog" feeds out there?  No.  Not all
metadata is burdensome.  Some is reasonable to require.

-- 
Cheers,
-Mark

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 29 Aug 2004 00:50:11 +0200

> required in every version of RSS since 1999, and in CDF before that.

How many RSS tools exist that lets you create RSS channel documents with  
default titles of «Untitled RSS channel», «Welcome to RSS Tool 4!» or  
something similar?

> Not all metadata is burdensome.  Some is reasonable to require.

<link rel="alternate"> is not purely metadata. It's also a requirement for  
duplication of data which in case <link> was optional, would not be  
duplicated.

If I want to publish my CD collection (or whatever) as Atom entries in an  
Atom feed, why do I need to have HTML documents of each CD to which I  
refer from the Atom entries inside the feed?

---

From: Tim Bray <[email-masked]>
Date: Sat, 28 Aug 2004 16:02:20 -0700

I think Asbjørn and others have presented plausible cases for feeds you 
might create where there's not an instantly-obvious choice for the 
"alternate" link.  Still, I think we should require them; at least you 
can point to an HTML page somewhere with a human-readable description 
saying "This feed describes variations in the readings from the 
potentiometer X328951 in rack 211-B" or something.  Among other things, 
if you ran across such a feed in the wild and didn't know what it was 
about, having a standard link to follow to find out would be nice.  And 
the cost is low.  -Tim

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 29 Aug 2004 01:21:52 +0200

On Sat, 28 Aug 2004 16:02:20 -0700, Tim Bray <[email-masked]> wrote:

> potentiometer X328951 in rack 211-B" or something.

What about required «alternate» links from entries? And why do one need  
this alternate link? Can't it at least be «about»?

> Among other things, if you ran across such a feed in the wild and
> didn't know what it was about, having a standard link to follow to find
> out would be nice.  And the cost is low.

For the feed, the cost is acceptable. For the entries, it's imho not.

---

From: Graham Parks <[email-masked]>
Date: Sat, 28 Aug 2004 19:31:23 -0400

>web resources for which Universal Resource Identifiers can not be provided.

Atom entries. "Web resource" is used several times in the charter to refer to Atom entries. Yet the charter says the designated format for Atom entries to be published in is "representing multiple resources in a single document". Only the docuemtn will have a resolvable URI - the resources won't.

Addtionally, good luck using the word MUST to describe this requirement:
"In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm"

>explorations of new possible applications.

It might help if the secretary and chairs spent less time telling everyone to shut up, and more time trying to recognize or encourage consensus.

Graham

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Sun, 29 Aug 2004 01:37:38 +0200

On Sat, 28 Aug 2004 02:53:14 +0900, Toru Marumoto <[email-masked]>  
wrote:

> You are supporsed to click on the title to see the acutural content on  
> the web in a web browser.

Looking at stats from my personal blogs, I tend to disagree. I have more  
visitors to the full-content feeds than to all other feeds combined.

I am +1 on making <link rel="alternate" /> a MAY instead of a MUST.

Anyhow: Could anyone say how much sense a <link rel="alternate" /> would  
make in the case of:

* Windows Event Logs via Atom?  
<URL:http://www.rassoc.com/gregr/weblog/archive.aspx?post=570>
* E-mail via Atom, <URL:http://www.iupload.com/product/mailbyrss.asp>

-- 
Arve Bersvendsen

http://www.virtuelvis.com
http://www.bersvendsen.com

---

From: Robert Sayre <[email-masked]>
Date: Sat, 28 Aug 2004 19:43:13 -0400

> Atom entries. "Web resource" is used several times in the charter to refer to Atom entries. Yet the charter says the designated format for Atom entries to be published in is "representing multiple…

The current draft no longer states or implies that the alternate link 
must be a web page or retrievable over http. If the entry doesn't have 
an alternate representation that can be identified by a URI, it isn't 
syndication--it's messaging. We're not here to deal with messaging.

Robert Sayre

---

From: Graham Parks <[email-masked]>
Date: Sat, 28 Aug 2004 19:50:45 -0400

>syndication--it's messaging. We're not here to deal with messaging.

http://dictionary.reference.com/search?q=syndication says:
"To sell (a comic strip or column, for example) through a syndicate for simultaneous publication in newspapers or periodicals."

Where does it say I have to publish a copy too?

Meanwhile, our beloved secretary is busy discussing using Atom for messaging on the other thread. Never mind.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Sat, 28 Aug 2004 19:59:06 -0400

> "To sell (a comic strip or column, for example) through a syndicate for simultaneous publication in newspapers or periodicals."

LOL. Where does that definition say anything about what we're doing here?

Yes, we have a new sense of the word "syndication" here. Cite prior art 
in RSS/RDF/CDF and I'll acknowledge your point, and it won't violate the 
charter either.

Please refrain from ad hominem attacks on this list. It makes it hard 
for people who agree with you to support your point of view.

If you have issues with the way the WG is being run, your recourse is to 
contact the Applications Area Directors.

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Sat, 28 Aug 2004 18:17:07 -0600

On Saturday, August 28, 2004, at 05:43  PM, Robert Sayre wrote:
> If the entry doesn't have an alternate representation that can be 
> identified by a URI, it isn't syndication--it's messaging. We're not 
> here to deal with messaging.
>
That depends on how you define syndication.  From the charter: "The 
feed format enables syndication; that
is, provision of a channel of information by representing multiple 
resources in a single document."  That doesn't say anything about each 
of those resources existing both within and without the feed.

The preceding sentence: "Atom defines a feed format for representing 
and a protocol for editing Web resources such as Weblogs, online 
journals, Wikis, and similar content."  What is a "web resource"?  Is 
the web HTTP?  HTML?  HTTP+HTML?  Was this sentence intended to 
preclude consideration of other "internet resources"?  In particular, 
are the Atom feed itself or its entries "web resources"?  An entry is 
certainly "similar content" to a weblog entry, and a feed to a weblog.

Is the required link merely a ritual cat that we're going out of our 
way to tie up, or is there a cat out there that's going to do something 
bad if we don't tie it up?  It just seems to me that we're making a 
requirement which limits Atom's flexibility without providing any 
benefit.  Unless processing feeds without links would be non-trivially 
difficult, why require links?

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 29 Aug 2004 02:26:56 +0200

On Sat, 28 Aug 2004 19:43:13 -0400, Robert Sayre <[email-masked]>  
wrote:

> identified by a URI, it isn't syndication--it's messaging.

Where did you read that definition? Why do you need an external copy, in  
an alternate format, for each entry to be able to call it «syndication»?  
Isn't the point of syndication to (re-) publish a news item in several  
places (at once)? How can this in any way conflate with messaging, and  
anyhoo: Why can't Atom be used for messagin?

> We're not here to deal with messaging.

If you're so certain that entries without alternate, external  
representations can't be syndication, why can't Atom deal with messaging  
too?

I'm in the opinion that syndication is something else, but nonetheless, I  
think Atom should cater for this exact need. Machine-to-machine  
communication should be possible to do, and in such cases, absolutely all  
alternate representations is nothing but extra work with absolutely no  
gain for anyone.

Most of the feeds that don't need or can't provide <link> for entries (or  
feeds, perhaps) won't be advertised as regular Atom subscription feeds.  
E.g., they won't say «Click here to subscribe to Xyz!». Hence, they won't  
get users into huge problems where they suddenly have feeds that don't  
refer to HTML representations of the entries. Either way, that shouldn't  
be a big problem for anyone.

---

From: Robert Sayre <[email-masked]>
Date: Sat, 28 Aug 2004 20:43:56 -0400

Antone Roundy wrote:

> It just seems to me that we're making a 
> benefit.  

It's my personal opinion that defining Atom in terms of the resources 
listed in the charter buys us a lot of interop, because users have 
well-defined expectations about the content of Atom feeds. Do we even 
have a use-case here? (I realize we may)

 > Unless processing feeds without links would be non-trivially

I think the term "processing" is misleading. Yes, parsing them and 
presenting them would be easy. Exactly what you would find inside is a 
different matter. At some point, "flexible and general" becomes 
"useless". Yes, this is a judgment call. You're free to propose 
amendments to the charter that would keep our problem tractable.

Robert Sayre

---

From: Toru Marumoto <[email-masked]>
Date: Sun, 29 Aug 2004 10:17:11 +0900

>representations can't be syndication, why can't Atom deal with messaging  

 I think it's gonna be developers nightmare if alternate representation was not required.
And it actually reduces the interoperability too.

so let's keep it simple. (make it required)

Toru Marumoto
     see you on the web!

--------------------------------

---

From: Dare Obasanjo <[email-masked]>
Date: Sat, 28 Aug 2004 18:59:16 -0700 (PDT)

--- Tim Bray <[email-masked]> wrote:

> Among other things, 

According to the protocol spec 

"alternate: The URI in the href attribute points to an
alternate representation of the containing resource."

Using this definition please tell me what the
alternate should be for a feed for a mailing list or
USENET newsgroup? Are you and Mark Pilgrim [who seems
to be the other person strongly arguing for mandatory
alternate links in feeds claiming that either (a) I
have to create a web page for a mailing list or
newsgroup before I can syndicate it with Atom or (b)
this is not an expected use case for Atom? 

=====

_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush

---

From: Robert Sayre <[email-masked]>
Date: Sat, 28 Aug 2004 22:20:57 -0400

> this is not an expected use case for Atom? 

Use the 'nntp' or 'news' schemes. The current format draft requires only 
that the alternate link contain a URI.

Robert Sayre

---

From: Dare Obasanjo <[email-masked]>
Date: Sat, 28 Aug 2004 19:31:35 -0700 (PDT)

> that the alternate link contain a URI.

And I guess you suggest I use the 'mailto' scheme for
mailing lists. That's fine, in which case the name
alternate doesn't accurately describe the value or
purpose of the attribute then. Secondly the value of
the alternate spec is defined in the protocol spec[0]
and it states 

or are there drafts of the spec more recent than
http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-01.txt

[0] It is really irritating to have to jump to the
protocol spec when looking up anything that has to do
with values for the rel attribute of links. 

=====

		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

---

From: Robert Sayre <[email-masked]>
Date: Sat, 28 Aug 2004 22:41:57 -0400

Dare Obasanjo wrote:

> mailing lists. 

No, I do not. I don't think that qualifies as an alternate 
representation, while Usenet URIs do, IMO. Perhaps you've caught me in 
some sort of contradiction here, but I think the intent of the spec is 
clear.

> That's fine, in which case the name

If you don't have an alternate, I don't have an answer. Alternate 
representations seem to be an integral part of syndication.

> http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-01.txt

There is no more recent draft. I believe the IETF will delete 01 when 02 
is made available.

> with values for the rel attribute of links. 

I agree with you 100% and I have consistently advocated moving that 
section to the format spec. I would support "PaceLinkRelationsInFormat".

Robert Sayre

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Sun, 29 Aug 2004 04:53:43 +0200

On Sat, 28 Aug 2004 18:59:16 -0700 (PDT), Dare Obasanjo <[email-masked]>  
wrote:

> USENET newsgroup?

I can't answer for mailing lists, but Usenet has the news: and nntp: URL  
schemes for accessing messages. See sections 3.6 and 3.7 of RFC 1738.

(I still do not support mandatory links to alternate content.)

-- 
Arve Bersvendsen

---

From: Tim Bray <[email-masked]>
Date: Sat, 28 Aug 2004 22:02:58 -0700

Hmm, this is an interesting discussion, and upon reviewing our charter, 
I don't think it really provides a slam-dunk case for either side to 
tell the other to shut up.

We have seen interesting examples from Dare and Asbjørn of places where 
Atom might well be a good fit but there's no obvious, natural candidate 
for the alternate link.  So this is a benefit of not requiring the 
alternate link.   OK, then, let's do some cost-benefit analysis: what's 
the cost?  If the cost is zero, or we come to generally believe that 
it's lower than the benefit, then the idea looks attractive.  I'm not 
asking this question rhetorically; if it's been addressed on the list I 
missed it (perfectly possible).

Put another way, I think it's worth investing some discussion on the 
technical trade-offs here rather than charter language and the 
definition of the word "syndication".  -Tim

---

From: Eric Scheid <[email-masked]>
Date: Sun, 29 Aug 2004 20:15:54 +1000

On 29/8/04 11:59 AM, "Dare Obasanjo" <[email-masked]> wrote:

> (a) I have to create a web page for a mailing list or newsgroup before I can
> syndicate it with Atom or (b) this is not an expected use case for Atom?
> 
<snark> also publish it as RSS </snark>

e.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 29 Aug 2004 13:02:37 +0200

> I think it's gonna be developers nightmare if alternate representation  

Huh? Surely, you're talking about consumer developers, then?

> And it actually reduces the interoperability too.

Why? How?

> so let's keep it simple. (make it required)

Simple for whom?

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 29 Aug 2004 13:41:45 +0200

On Sat, 28 Aug 2004 22:20:57 -0400, Robert Sayre <[email-masked]>  
wrote:

>> (a) I have to create a web page for a mailing list or newsgroup before
>> I can syndicate it with Atom
>

But what is then the actual _use_ of <link rel="alternate">? I mean, if  
the intent is that human readers should be able to click the URI and then  
get some human readable resource thrown up in a browser widget or  
whatever, how is this going to work for any other URI scheme than HTTP?

Are we expecting Atom readers (humans) to have user agents for all these  
different schemes installed, or are we expecting Atom clients  
(applications) to build in support for all these schemes?

If the answer to the above questions are «no», then can someone please  
tell me what good

   <link rel="alternate" type="text/plain"
     href="nntp://news.example.com/alt.example/2342" />

or

   <link rel="alternate" type="text/plain"
     href="news:[email-masked]" />

is supposed to do to anyone?

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 29 Aug 2004 13:47:34 +0200

On Sat, 28 Aug 2004 22:41:57 -0400, Robert Sayre <[email-masked]>  
wrote:

> representation, while Usenet URIs do, IMO.

Okay, so in a non-archived mailing list, what are you going to do, then?  
Do you have to create an HTML archive for the sole purpose of accomodating  
the specification?

> Perhaps you've caught me in some sort of contradiction here, but I
> think the intent of the spec is clear.

The original intent is clear. The problem is that it constrains to a major  
degree what Atom can be used for.

> representations seem to be an integral part of syndication.

It might be an integral part of RSS syndication, but not syndication in  
any other aspect of real life (where the word actually comes from. It  
wasn't created by Dave Winer) and thus should it not be in Atom either,  
imo.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 29 Aug 2004 14:03:56 +0200

On Sat, 28 Aug 2004 22:02:58 -0700, Tim Bray <[email-masked]> wrote:

> OK, then, let's do some cost-benefit analysis: what's the cost?

The cost of having to provide alternate representations for all resources  
exposed as Atom documents is huge. Think of non-archived mailing lists. My  
personal CD collection. News events of a football match. TV listings.  
«Last played» lists for radio. «Next 10» lists for radio.

Also, if a URI scheme or format is not mandated, I don't understand the  
intent of <link rel="alternate">. I mean, if I can just put <link  
rel="alternate" type="text/javascript" href="javascript:alert('hello')" />  
in my feeds to satisfy the specification, who gains from that?

At least, if the specification mandated 'text/html' (or variations of it)  
for @type and the HTTP scheme for @href, it would be useful as an  
easy-retrievable, human readable, alternative representation. If all URI  
schemes and all content types are allowed, then what is the point?

I'd also like to not that Dare, who creates a highly used RSS and Atom  
aggregator, don't see the point in having this alternate link. If this  
link isn't useful to an aggregator or aggregator users, and don't cause  
anything to break if it's missing, why do we need it?

Which cat are we tying up for what reason here?

---

From: Sam Ruby <[email-masked]>
Date: Sun, 29 Aug 2004 08:52:21 -0400

> definition of the word "syndication".  -Tim

Fair enough.

My preference is that the alternate link (possibly renamed) remains 
required.  The feed readers that I am aware of all provide the ability 
to launch the alternate view of a feed.  By contrast, each has to 
provide a set of logic to search for a number of different ways in which 
the alternate view of an entry may (or may not be) provided.

To put this in a larger context: RSS 1.0 has a tiny core and lots of 
extensions.  The other RSS fork took some of these interesting ideas and 
put them into the core[1] - as options.  I claim that having notions 
such as ids (in rss 2.0) and dates (in both) as options hurts 
interoperability.  Similar observation on there being two ways in the 
core of RSS 2.0 to specify an item permalink, both optional.

A final note: to date, this question has been phrased a bit too 
hypthetically for me - it seems to be of the nature "how would I handle 
a set of feeds that nobody is currently providing".  By contrast, 
however, something that WOULD attract my attention is somebody saying 
"here is a set of feeds that I would like to provide that I can't 
provide in a valid way according to any of the available RSS 
specifications."

- Sam Ruby

[1] http://groups.yahoo.com/group/syndication/message/218

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 29 Aug 2004 06:37:22 -0700 (PDT)

> the alternate view of an entry may (or may not be)

The feed readers you are aware of can launch the
website for a particular feed. It seems very limiting
to assume that only websites can syndicate content. 

> core of RSS 2.0 to specify an item permalink, both

http://www.datanation.com/fallacies/falsean.htm

Analogies are a weak way to debate. Claiming that
since not having required IDs and dates is bad for
interop does not translate to not requiring some other
field being bad for interop. 

Please describe how interop is hurt by not having this
field instead of arguing by analogy. 

> provide in a valid way according to any of the

This isn't a hypothetical question. Google is already
providing Atom feeds for USENET so this isn't
hypothetical. However since all the feeds they'd
syndicate show up in http://groups.google.com they
don't have this problem since they can always point to
that site. I'm currently implementing NNTP support in
RSS Bandit and currently would like to use the same
archive format for syndication feeds and USENET. 

 Currently I only plan to use it as a synchronization
source since they upped the space limit to 250MB.
However it is conceivable that Hotmail support could
end up in RSS Bandit in a year or so. Again I'd like
to have a uniform archive format. Also, there are
feeds for this mailing list syndicated today but since
it has an online archive the feeds can point here.
Similarly someone at MSFT is working on a patch that
allows RSS Bandit to communicate with Hotmail.

Basically it seems you are claiming that that unless a
mailing list or newsgroup is archived on the Web it
can't be syndicated in Atom. That sounds like an
arbitrary and unnecessary restriction. 

=====

---

From: Sam Ruby <[email-masked]>
Date: Sun, 29 Aug 2004 10:01:38 -0400

> field instead of arguing by analogy. 

It was not my intent to argue by analogy.  I thought I was clear: I was 
trying to explain the larger context in which I was looking at this 
issue.  However, since I was less than successful the first time, let me 
try again:

My overall thought process when modelling a syntax for interop loosely 
goes this:

1) can this feature be REQUIRED?
2) if not, can this feature be placed in an EXTENSION?
3) if none of the above, then consider an OPTION.

Any individual optional element may be defensible, what would concern me 
is a pattern of replacing required elements with optional elements.

More specifically, what I am looking for is a compelling reason why feed 
links can't be required and can't be an extension.

Different people may have different thought processes, but those are 
mine.  FWIW.

> allows RSS Bandit to communicate with Hotmail.

I accept that an archive format based on Atom may have different 
requirements (particularly with respect to cardinalities) than a 
syndication format.  You and I have discussed this before - in the 
context of dates.

> arbitrary and unnecessary restriction. 

Please don't put words in my mouth.

- Sam Ruby

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Sun, 29 Aug 2004 16:33:50 +0200

> links can't be required and can't be an extension.

* Because there already are uses _in the wild_ with RSS for which there is  
no sensible alternate content. See  
<URL:http://www.imc.org/atom-syntax/mail-archive/msg09150.html>
* Because people (on this list, even) see near-term future uses of Atom  
where an alternate representation is not appropriate.

-- 
Arve Bersvendsen

---

From: Bill de hÓra <[email-masked]>
Date: Sun, 29 Aug 2004 15:39:49 +0100

Robert Sayre wrote:

> If the entry doesn't have 
> syndication--it's messaging. 

It's incidental, but I don't agree with that characterization.

cheers
Bill

---

From: Bill de hÓra <[email-masked]>
Date: Sun, 29 Aug 2004 15:44:20 +0100

> is supposed to do to anyone?

I imagine it relies on the idea that a number of client readers 
embed browsers or browser components to render web content rather 
than code the rendering from scratch. The browsers in question can 
switch based on the protocol.

cheers
Bill

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 29 Aug 2004 17:54:59 +0200

On Sun, 29 Aug 2004 15:44:20 +0100, Bill de hÓra <[email-masked]> wrote:

> I imagine it relies on the idea that a number of client readers embed  
> browsers or browser components to render web content rather than code  
> the rendering from scratch.

This is the machine-to-human use case of Atom. It also implies that such  
browser widgets are available for the given platform and environment.  
Shouldn't it be possible to create Atom user agents that don't have a  
visual rendering API, like console applications, for instance?

Either way, there are a lot of compelling use cases for Atom that is _not_  
machine-to-human, but machine-to-machine. And even in many  
machine-to-human scenarios, the humans really don't care about alternative  
representations, as Arve told about his feed reading statistics.

> The browsers in question can switch based on the protocol.

Not all of them can. How many support the NNTP scheme, for example? Or  
NEWS, for that matter? What other schemes would be acceptable, and which  
would not be?

Should the acceptable schemes be enumerated in the specification, or  
should it be silent, but still require <link rel="alternate">? If so, it  
is perfectly allowable to say:

   <link rel="alternate" type="application/rtsl"
     href="rtsp://example.com/example_stream.rm" />

RTSP is a registered URI scheme:

   <url: http://www.iana.org/assignments/uri-schemes>
   <url: http://www.ietf.org/rfc/rfc2326.txt>

What browser widgets support the RTSP URI scheme? Or the VEMMI scheme? Or  
the SIP, SIPS, TEL, FAX or MODEM schemes? If <link rel="alternate"> is  
going to be useful, the allowed or recommended schemes and content types  
needs to be enumerated. I would still not support it being required, but  
then it would at least purport the right intent.

(If I have understood the intent correctly, it is to give an alternate,  
easy-retrievable and human readable representation of Atom resources. If  
the intent is something else, please let me know. If someone thinks this  
intent is met without requiring URI schemes and content types, please tell  
me about that as well.)

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 29 Aug 2004 18:05:10 +0200

* Mark Pilgrim wrote:
>Are there thousands of "Untitled blog" feeds out there?  No.

Just like there are not millions of home pages without a customized
title either, most documents lacking a proper title are sub-pages;
but there are thousands of feed entries with titles like

  * [Insert Witty Title Here]
  * insert clever title here
  * [Click to Insert Title]
  * Click To Add Title
  * Insert Title Here
  * Untitled document
  * ADD A TITLE HERE
  * Untitled Entry
  * (no title)
  * No Title
  * Untitled
  * Title
  * ...

some even have something like

  * Can't think of a good title
  * heh...to tired to think of a good title 
  * I had a really good title for this. Really, I did.
  * No good title comes to mind...
  * Monday (Because I Couldn't Think of a Good Title)
  * I can never think of good subject titles
  * uh... can't think of a good title...
  * No Good Titles Before 10am
  * I suck at making up titles, so just insert something good here.
  * Can't Think of a good title...sorry 
  * dont really have a good subject title lol
  * ...

I wonder whether these are two classes of software, such that require
changing the "default" title and such that do not... So, what exactly is
the point of mandating meta data if software or people do not provide it
properly but rather some "junk" instead just to satisfy the requirement?

>Not all metadata is burdensome.  Some is reasonable to require.

RFC 2119 requires,

[...]
  Imperatives of the type defined in this memo must be used with care
  and sparingly.  In particular, they MUST only be used where it is
  actually required for interoperation or to limit behavior which has
  potential for causing harm (e.g., limiting retransmisssions)
[...]

Is it required for interoperation that Atom documents have an alternate
representation and refer to it? Does it have potential for causing harm
when such information is missing? No. Such a requirement is as pointless
as the requirement that renders http://diveintomark.org/ non-conforming,
section 14.2.1 of the HTML 4.01 Recommendation. I am as surprised that
feeds are required to have alternate representations as most standards
savy authors are surprised by that requirement; conformance requirements
should be obvious, not surprising -- they'll be ignored otherwise.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 29 Aug 2004 18:16:49 +0200

>potentiometer X328951 in rack 211-B" or something.

Users are going to get disappointed if such a document is sold to them
as an alternate HTML representation of the feed and think twice about
following such a link next time. This is very much like <img alt="*"
...> versus <img alt="rotating circle with fancy blue border" ...>.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 29 Aug 2004 18:24:51 +0200

>representations seem to be an integral part of syndication.

The Atom Publishing Format *enables* syndication, but it is not limited
to it, at least not as far as I can tell from our Charter.

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 29 Aug 2004 12:41:28 -0400

Asbjørn Ulsberg wrote:
> Should the acceptable [URI] schemes be enumerated in the
> specification...?
	Absolutely NO. Doing this would border on insanity. 
	It is perfectly ok if the URI scheme used as an "alternate" is
not supported by all clients. Heck, I can show you clients that process
Atom feeds but don't support the http scheme! 
	Some clients know what to do with nntp:, news:, http:, https:,
and even rtsp: and gopher:. The fact that all clients won't know how to
handle every scheme is not a bug.

		bob wyman

---

From: Sam Ruby <[email-masked]>
Date: Sun, 29 Aug 2004 12:43:33 -0400

Arve Bersvendsen wrote:
>> More specifically, what I am looking for is a compelling reason why 
>> feed  links can't be required and can't be an extension.
> 
> * Because there already are uses _in the wild_ with RSS for which there 
> is  no sensible alternate content. See  

Perhaps I missed it, but I don't see an argument against making link an 
extension in the above?

The down side of not having a link be required is that it opens up the 
possibility of there being multiple distinct ways to express the concept.

There already is a syndication format where there is two distinct ways 
to express an entry permalink in the core, and a number of extensions 
which can be used to replace those core elements.

Note that I am I'm not saying that we shouldn't do this here, but I am 
saying that we need to be careful and consider both the upsides and the 
downsides.

- Sam Ruby

---

From: Dan Brickley <[email-masked]>
Date: Sun, 29 Aug 2004 12:54:40 -0400

* Bob Wyman <[email-masked]> [2004-08-29 12:41-0400]
> handle every scheme is not a bug.

+1

Some things are best left to the marketplace...

Dan

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 29 Aug 2004 10:08:52 -0700 (PDT)

> 3) if none of the above, then consider an OPTION.

Interesting. I have totally different approach. Like
Anders Hejlsberg keeps telling us at work every
feature should start with a 1000 points against. Add 1
for every good reason to have it, if you get to 0 then
ship the feature otherwise it isn't worth the cost.
It's a variation of "The hallmarks of a good design is
when you have nothing left to take out". 

> syndication format.  You and I have discussed this

OK. 

> Please don't put words in my mouth.

Fine, then what is your position on whether feeds like
http://groups-beta.google.com/group/microsoft.public.xml/feed/msgs.xml
and http://rss.groups.yahoo.com/group/rss-dev/rss
should be possible for newsgroups and mailing lists
that are not archived on some public website? 

=====

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 29 Aug 2004 10:14:28 -0700 (PDT)

> handle every scheme is not a bug.

Ignoring that this makes 'alternate' a bad name for
the rel value how exactly does this not make interop
worse? On the one hand, a feed author can decide that
if they don't a website for the contens of the feed
they can omit adding the link to the feed. This mean
when users click 'Go to feed website' in the
aggregator it reports back there is no website for the
feed. This is a trivial check for me to add in RSS
Bandit. On the other hand, feed authors are encouraged
to arbitrary URI schemes such as mailto, nntp & news
in there. The user clicks 'Go to feed website' and the
user gets some ugly error message or at best a broken
link. How is this making interop better? 

=====

---

From: Sam Ruby <[email-masked]>
Date: Sun, 29 Aug 2004 13:24:37 -0400

> when you have nothing left to take out". 

It has been said that analogies are a weak way to debate.  But based on 
this analogy with program products, I gather that your impression is 
that Anders would argue that the link element should be moved out of the 
core, and into an extension?  Would this help or hurt interoperability?

I don't know about you, but I find these word games tiring.

- Sam Ruby

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 29 Aug 2004 10:31:46 -0700 (PDT)

> I don't know about you, but I find these word games

I asked you a question about feeds for USENET and
mailing lists. I'd rather you answer that than trying
to get into a debate over our different personal
design styles since that is just a waste of everyone's
time. 

You said the first question you ask yourself is
"should it be required?" I was responding by letting
you know that the first question I ask myself "should
the feature exist?" I assume you felt there was some
usefulness in explaining your personal design style
and I was reciprocating so you know where I'm coming
from. I doubt I'll change your mind on how you should
approach Atom design and I don't think your going to
change mine. 

=====

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 29 Aug 2004 19:59:39 +0200

> Absolutely NO. Doing this would border on insanity.

I agree. Which is why <link rel="alternate"> should be optional.

> not supported by all clients.

So <link rel="alternate" type="text/plain"  
href="data:My%20alternate%20content" /> is better than no <link> at all?

> Heck, I can show you clients that process Atom feeds but don't
> support the http scheme!

Okay. My question still remains unanswered. Is it better with garbage  
content in <link> than no <link> at all?

---

From: Bill de hÓra <[email-masked]>
Date: Sun, 29 Aug 2004 20:48:08 +0100

Asbjørn Ulsberg wrote:

> This is the machine-to-human use case of Atom. 

Maybe it is.

> It also implies that 
> such  browser widgets are available for the given platform and 
> environment.  Shouldn't it be possible to create Atom user agents that 
> don't have a  visual rendering API, like console applications, for 
> instance?

Maybe. I was just thinking about an ability to switch on URI scheme.

> Either way, there are a lot of compelling use cases for Atom that is 
> _not_  machine-to-human, but machine-to-machine. And even in many  
> machine-to-human scenarios, the humans really don't care about 
> alternative  representations, as Arve told about his feed reading 
> statistics.
> 
> Not all of them can. 

I suppose those would be the browsers not in question.

> How many support the NNTP scheme, for example? Or  
> NEWS, for that matter? What other schemes would be acceptable, and 
> which  would not be?

You're arguing with me as though I was adverse to your position. I'm 
not - you asked a question and I answered it. I'm not making any 
claims or objections beyond my answer.

cheers
Bill

---

From: Bill de hÓra <[email-masked]>
Date: Sun, 29 Aug 2004 20:58:48 +0100

> design styles since that is just a waste of everyone's

Indeed, suddenly it's a waste of everyone's time. But you did care 
to point out someone else's style was not your design style and 
mention a design style not like it. But if you do feel it's a waste 
of my time, a response in kind is surely the wrong action.

It's one to thing to point out argument from analogy is waste of 
time. It's another to be caught engaging in just that, and then make 
general objections in the direction of the person pointing it out 
instead of admitting it.

cheers
Bill

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 29 Aug 2004 16:13:05 -0400

Dare Obasanjo wrote:
> The user clicks 'Go to feed website' and the
	Sounds like a poorly implemented client to me...
	Atom should or can only make interop promises concerning data which
is in Atom format or about the mechanisms by which alternate data
representations are addressed. Atom can no more require that all alternative
representations be in some version of HTML that is universally understood
(no such version exists) nor should it attempt to constrain all alternative
formats to some known set. Atom goes far enough in providing a consistent
mechanism for passing data in Atom format and for consistently encoding
links to alternatives.
	I use Outlook Express as my NNTP News reader. Thus, when I click on
a link to an NNTP newsgroup or to a specific NNTP message (identified with a
"globally unique id"), Outlook Express is called and will open a window with
either the newsgroup or the specific message in it. This is done with the
assistance of Windows file associations, browser extensions, etc. Similar
behavior, but with different tools, results if I click on an alternate which
is gopher:, ftp:, etc.
	Atom does all it can be asked to do when it provides a consistent
mechanism to address alternative content. It is up to the client developers
to develop mechanisms to support a wide variety of alternatives. My guess is
that those clients which support a wider variety of protocols will end up
being more successful in the long run. The definition of Atom should not
attempt to restrict this avenue for competitive differentiation.

> This mean when users click 'Go to feed website' in the
> feed.
	This sounds like bad, inflexible, HTTP-centric client design. The UI
should only say "go to website" if, in fact, the protocol in the URI is http
or https. It would be improper to suggest that a newsgroup or entry in a
newsgroup should be called a "website."

> On the other hand, feed authors are encouraged
> to arbitrary URI schemes such as mailto ...
	I would argue that "mailto" would not be an appropriate scheme for
an "alternate" link since mailto is not used for retrieval but rather is
used for addressing messages. This class of scheme should be prohibited from
use in an "alternate" link since it can't be used to *retrieve* an alternate
representation of the entry -- no matter how well the client is implemented.

		bob wyman

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 29 Aug 2004 13:18:45 -0700 (PDT)

> general objections in the direction of the person

Why do you feel obligated to post some personal attack
in every thread I am in? Did I owe you money in a past
life or something?

Besides getting in another snide personal attack  what
purpose does your response serve? Do you have any
value to add to this thread besides indirect and
passive-aggressive flaming? 

=====

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 29 Aug 2004 13:28:59 -0700 (PDT)

It seems we aren't start from the same basis. What is
the purpose of alternate? The impression I've gotten
from the few people who have piped to claim that it
should be mandatory are basically users of what you
have described as 'poorly implemented clients'. 

So if the feature is only useful to broken tools why
are we even bothering to have it in Atom at all let
alone debating whether it should be required or
optional? 

By the way, no one has put forward a case for what
should be done with <link rel="alternate" /> when it
comes to mailing lists. I notice the folks arguing
that it should be required are either ignoring this
question or have admitted there is no good value to
put there. This already feels like a bad smell in the
design for me. 

=====

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 29 Aug 2004 16:30:56 -0400

> href="data:My%20alternate%20content" /> is better than no

	The example you gave does not conform to the requirements of the
"data" URL scheme as documented in RFC2397. In order to conform to RFC2397
you would have to rewrite the href attribute as:
	Href="data:,My%20alternate%20content"
	The problem is that you left out the comma "," which is required
syntax. See Section 4 of RFC2397[1] for a similar example.

	Nonetheless, as long as you pass the data in a manner which conforms
to the data URI scheme, I don't see why it wouldn't be supported. Please
note that "data" is only useful for small bits of data and is subject to
processors' limitations on the length of URI's, etc. Also, please note that
very few clients are likely to support this URI scheme. Thus, it would make
sense for you to try your best to find an alternative alternate.

> content in <link> than no <link> at all?
	There should be no "garbage" content. Whatever is provided should be
syntactically correct and have some meaning. At worst, point to a page that
says that no alternate is available or that provides guidance on how to
obtain alternates via mechanisms other than URI-dereferencing.

		bob wyman

[1] http://www.ietf.org/rfc/rfc2397.txt

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 29 Aug 2004 23:45:02 +0200

On Sun, 29 Aug 2004 16:30:56 -0400, Bob Wyman <[email-masked]> wrote:

> "data" URL scheme as documented in RFC2397.

Well, my point was not to provide a conformant example either. I agree the  
example should have been, but my point would be the same nonetheless.

> to the data URI scheme, I don't see why it wouldn't be supported.

But how does it improve interoperability to have syntactically and  
conformant, but completely useless, URI's in <link rel="alternate">? They  
should be provided to improve interoperability, right? But how is:

   <link rel="alternate" href="data:text/html;base64,
     VGhpcyBpcyBzb21lIDxzdHJvbmc+YWx0ZXJuYXRlPC9zdHJvbmc+IGNvbnRlbnQu" />

more interoperable, or in any way better, than having no <link> at all?

> Please note that "data" is only useful for small bits of data and is
> subject to processors' limitations on the length of URI's, etc.

Yes, but as long as it is within all these limitations and conforms to all  
of RFC 2397's rules, any alternate content could be put into this scheme.  
Even the whole entry itself.

If <link> is required, this is most likely what I'll do; I'll  
base64-encode the whole entry (maybe after it's converted to HTML, as if  
that helps) and squeeze it into @href using the DATA scheme. All  
conformant and well, but totally useless.

> Also, please note that very few clients are likely to support this URI
> scheme.

Does that matter? There isn't a «CD's on my local computer» scheme, so the  
DATA scheme is the closest scheme I'll ever get to that one.

> Thus, it would make sense for you to try your best to find an alternative
> alternate.

It doesn't make sense for me to find an alternate at all.

> There should be no "garbage" content.

Content that is provided _only_ because the specification requires it is  
garbage. If no human or machine on the planet gains from having the <link>  
in the feeds I'm publishing, but the <link> is still provided, it's  
garbage.

> Whatever is provided should be syntactically correct and have some  
> meaning.

What meaningful easy-providable alternative do you have for the following:

   - USENET articles that aren't indexed by Google
   - My private CD collection
   - Non-archived mailing lists
   - News events of a football match
   - TV listings
   - «Last played» lists for radio
   - «Next 10» lists for radio

> At worst, point to a page that says that no alternate is available or  
> that
> provides guidance on how to obtain alternates via mechanisms other than
> URI-dereferencing.

Then that is not an alternate representation of the resource. And it would  
be a lot simpler to have this explanation in the DATA scheme, since that  
can be provided inline the feed. So, here's my workaround for this  
requirement:

   <feed version="draft-ietf-atompub-format-01: do not deploy"
     xmlns="http://purl.org/atom/ns#draft-ietf-atompub-format-01">
     <head>
       <title>Example Feed</title>
       <link rel="alternate" type="text/html" href="data:text/html;base64,
         VGhpcyBmZWVkIDxzdHJvbmc+ZG9lcyBub3Q8L3N0cm9uZz4gaGF2ZSBhbHRlcm5hd
         GUgY29udGVudC4=" />
       <modified>2003-12-13T18:30:02Z</modified>
       <author>
       <name>John Doe</name>
       </author>
     </head>
     <entry>
       <title>Atom-Powered Robots Run Amok</title>
       <link rel="alternate" type="text/html" href="data:text/html;base64,
         VGhpcyBlbnRyeSA8c3Ryb25nPmRvZXMgbm90PC9zdHJvbmc+IGhhdmUgYWx0ZXJu
         YXRlIGNvbnRlbnQu"/>
       <id>tag:example.org,2003:3.2397</id>
       <issued>2003-12-13T08:29:29-04:00</issued>
       <modified>2003-12-13T18:30:02Z</modified>
     </entry>
   </feed>

Since none of my subscribers care about the <link> element, it doesn't  
matter what it refers to. But to stay compliant with the specification, I  
alert in the <link> element that there isn't any alternate content.

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 29 Aug 2004 18:08:10 -0400

Dare Obasanjo wrote:
> the purpose of alternate?
	It would be too bad if all this heat was generated over a
misunderstanding... 
	My sense of things is that the "alternate" link is intended to
provide a link to an alternative representation of the content which the
atom:entry encapsulates. Looking back to the origins of RSS as "Rich Site
Summary", I see syndication files as a way to provide easily processed
representations of web pages and other resources. These easily processed
representations serve as alternatives for the original resources themselves.
The value of the Atom format comes in that it allows a more structured
representation of the original resource and allows, in some cases,
additional metadata (such as keywords, etc.) to be associated with a
resource in a way that wouldn't otherwise be possible.
	To me, it is precisely this ability of an RSS item or Atom entry to
stand as an alternate for a resource that makes it "obvious" that one would
want to expand as broadly as possible the variety of original source types
that are supported. By doing so, it becomes possible for a single format
(Atom) to provide useful proxy representations of content normally accessed
via HTTP, NNTP, Gopher, FTP, LDAP etc. This means that it is possible to
write fairly simple clients that provide at least limited access to
information published via a wide variety of protocols and formats (text,
html, pdf, dvi, xls, etc). This is a good thing since it significantly
lowers the barrier to entry into our multi-protocol/multi-format
environment. Publishers are able to choose the protocol or URI scheme and
the encoding formats that best address the particular needs of their
application while gaining the broadest possible ability to publicize and
disseminate their content, in whole or summary, via the Atom format.
	Using Atom, I can search for and discover new content no matter how
the original representations are accessed or how they are encoded. This is a
good thing. Clearly, it isn't the whole game... For instance, if I receive a
summary of item, I may still need to have support for http, ldap, or nntp to
actually access it and I might need to have support for html, pdf, etc. to
read the resource once retrieved. However, simply being able to read the
Atom proxy (alternate) and discover that the thing exists is often a big
part of addressing my needs.
	The discussion above assumes that Atom is intended to provide what
"Rich Site Summary" was trying to do. That is, the Atom entry should always
be considered the "secondary" item, not the primary. The primary item is
something that the Atom entry talks about, summarizes, or is a proxy for. If
this view is correct, then logically an alternate link CAN be provided since
for a proxy to exist there must first be an "other" as well. Given this role
for Atom entries, it makes sense that we say that the alternate MUST be
identified, since the entry makes no sense without reference to the cause of
its existence. 
	If, on the other hand, an Atom entry is to be permitted to stand on
its own as a primary, first-class object with no precedents, then the
alternate link would *clearly* be optional since it doesn't make sense to
*require* that all resources have alternatives.
	So, the question is: Can an Atom entry exist on its own? If so, then
alternate should be optional. If not, then it is reasonable to require it.
In any case, if provided, we should constrain neither the format of nor the
means of accessing the resources that the Atom entry is an alternate of.
	Do we agree on the purpose of alternate? If not, please explain how
you see it so that we can try to come to common ground.

	Note: I might even argue that we should support the URN schemes like
urn:issn or urn:isbn even though the "retrieval" protocol for these things
is something like: "Get in car, drive to bookstore or library, look on
shelf,..., etc."

> comes to mailing lists.
	I assume, since a link in this context must point to a retrievable
thing, that you meant to say "mailing list archives". In this case, I don't
think there is a universally accepted concept of what such an archive is.
SMTP/POP systems don't have an archive concept. IMAP and some other mailing
systems do have a concept of storage... Via the imap URI Scheme[1], one
could point to a shared folder containing an archive of traffic over the
list. However, for most mailing lists, I think the best you can do is have
an "http:" link that points to HTML pages. For instance, for this list your
feed link would point to:
	http://www.imc.org/atom-syntax/index.html
For a specific message (entry) in the feed, you would have a pointer like:
	http://www.imc.org/atom-syntax/mail-archive/msg09227.html
(Note: I am aware that the message id is not always available until *after*
a message has been inserted into the email archive -- the message id can't
always be extracted from a message itself. This is something that mailing
list archive developers will hopefully address in the future... One way to
do this would be to use the message id to identify messages in the archive.
For instance, the message I'm replying to here has message id:
<[email-masked]>) Thus, the preferred
http: link would be:
http://www.imc.org/atom-syntax/mail-archive/20040829202859.22626.qmail@web41
213.mail.yahoo.com . An alternative would be for the list software to
include its own message id as a header field in outgoing email. Each method
has pros and cons.)

		bob wyman

[1] http://www.ietf.org/rfc/rfc2192.txt

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 29 Aug 2004 18:54:45 -0400

Asbjørn Ulsberg wrote:
> conformant, but completely useless, URI's in <link rel="alternate">?
	A "data:" resource is only useless to you if your *client* or
application doesn’t understand them. Just as an "http:" or "nntp:" resource
is useless if your client doesn't understand http or nntp. What you are
talking about is a limitation of your client -- not a problem with the
format!
	In any case, by providing a common, consistent format for making
statements about resources, Atom provides a great deal of interoperability
between applications that support Atom. It means that even if your
application doesn't understand the precise access method required to access
a resource, you can still find out about it and often use the Atom entry as
a completely satisfactory proxy for the inaccessible resource. This is
goodness. 

		bob wyman

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 29 Aug 2004 18:21:26 -0700 (PDT)

> atom:entry encapsulates
...
> environment. 
...
> reference to the cause of

I agree with this perspective. Although I'd probably
name the rel value "original" as opposed to
"alternate" then. 

> reasonable to require it.

I haven't heard an argument for why an Atom entry
can't be a standalone item. So far the only arguments
I've heard from folks like Sam Ruby, Tim Bray and Mark
Pilgrim is "that's how it was done in RSS". 

> you see it so that we can try to come to common

I don't believe it should be called alternate but I
agree that some identifier letting the client what the
data in the feed mirrors (if anything) is useful. 

> think there is a universally accepted concept of

No, I meant mailing lists although as you point out
even the simpler concept of mailing list archives is
still difficult to express in a common fashion. 

<extremely-hypothetical>

For example, what if a corporate mail server could
expose mailing lists as RSS feeds for those who would
rather read high traffic lists in their aggregator as
opposed to their mail reader? Should the mail server
now have to create a dummy website for this mailing
list [and thus adding additional surface area for
getting hacked] for the express purpose of satisfying
some arbitrary constraint in the Atom spec? 

</extremely-hypothetical>

> For instance, the message I'm replying to here has
<[email-masked]>)
> Thus, the preferred
> outgoing email. Each method

But even after all this we are still stuck with saying
"If you can't put the mailing list archive on some web
site you can't syndicate it in Atom" which sounds like
an unreasonable restriction. 

=====

__________________________________
Do you Yahoo!?
Y! Messenger - Communicate in real time. Download now. 
http://messenger.yahoo.com

---

From: Robert Sayre <[email-masked]>
Date: Sun, 29 Aug 2004 21:48:11 -0400

> Pilgrim is "that's how it was done in RSS". 

If that's the answer for everything, we wouldn't be here. However, it is 
reasonable to ask why something so simple wasn't demanded from some 
version of RSS.

> an unreasonable restriction. 

The mailing-list-without-an-archive is not compelling, IMO. Someone 
should be able to state their own use case for Atom entries with no 
links. Why are people pressing for this, and why hasn't this issue come 
up in RSS... or has it? Are there vast numbers of invalid RSS feeds with 
no links?

Robert Sayre

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 29 Aug 2004 21:51:41 -0400

> name the rel value "original" as opposed to
	I agree with this and would support the use of "original" in place
of "alternate" since it is a much more accurate expression of what is
intended.

> Pilgrim is "that's how it was done in RSS".
	I think that "that's how it was done" is the most often used
explanation. To do something different, we'd have to make an explicit
decision. Frankly, I would be very pleased if an atom:entry could stand on
its own. It would make the format much more useful. Also, this would provide
one more very clear distinction between the specifications for RSS and Atom.
	However, even if the spec said that an atom:entry could be
free-standing, I think that it should also say that if an original URI is
available and known to the publisher of the entry, that it MUST be included
in the entry. (Yes, I realize that this restriction would be frequently
ignored.)

		bob wyman

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 29 Aug 2004 18:57:23 -0700 (PDT)

> up in RSS... or has it? Are there vast numbers of

Most RSS feeds in the wild are for websites. The
entire purpose of this discussion is about enabling
XML syndication to go beyond mirroring the content on
some website. However even then there's precendent in
the RSS world. 

There's the the Windows Event Log RSS feed[0] which
for the life of me I can't imagine what one would put
as a valid alternate link. Then there's the fact that
RSS 2.0 allows users to define standalone content with
no alternates [items with descriptions or titles but
no links].  

I've stated several use cases for feeds without
alternates as have others. Look in the archive if you
missed them. 

[0] http://www.rassoc.com/gregr/weblog/archive.aspx?post=570

=====

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 29 Aug 2004 19:03:18 -0700 (PDT)

> specifications for RSS and Atom.

Actually in responding to Robert Sayre I just
remembered that RSS 2.0 items can be free standing
since a link is optional. So you can have a feed with
items that just have titles and descriptions. 

+1

=====

---

From: Robert Sayre <[email-masked]>
Date: Sun, 29 Aug 2004 22:16:14 -0400

Dare Obasanjo wrote:

> Then there's the fact that

Don't know how I missed this, but I've asked for a precedent numerous 
times. I'm happy to eat crow.

+1 to no link required for entries.

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Sun, 29 Aug 2004 19:21:22 -0700

> Indeed, suddenly it's a waste of everyone's time. But you did care

I think meta-argument about rhetorical techniques is in bounds... but 
this particular thread has become both content-free and damagingly 
nasty.  Please do the WG a favor and stop it.  -Tim

---

From: Tim Bray <[email-masked]>
Date: Sun, 29 Aug 2004 19:30:34 -0700

> Pilgrim is "that's how it was done in RSS".

I agree with Bob Wyman's analysis of the alternate-link requirement 
being related to whether or not an entry can be standalone, and 
whatever I may have said previously, I'm beginning to find the 
arguments for making the link optional increasingly persuasive.

Particularly since, in an aggregator, I can't see how I'd have any 
trouble handling them... if I was human-facing and there was no link, 
or a link with a URI scheme that I didn't know, I'd display the entry 
but make nothing clickable.  So what?  If people didn't like using that 
kind of feed they wouldn't subscribe to it.  Also I've had several 
potential machine-to-machine applications of Atom presented to me 
offline in recent months, so those arguments are I think worth 
listening to. -Tim

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 29 Aug 2004 22:49:33 -0400

Note: This business of "standalone" Atom Entries would not be completely
painless... It would force us to make some changes at PubSub.com... We now
offer several services that assume that Atom entries have links. We'd have
to think carefully about how to modify our offerings if entries without
links are legal.

For instance, via our Atom over XMPP service[1], you can request either the
full content of an entry or you can request that the atom:content element be
excluded. Requesting that atom:content be excluded is very useful in
applications such as the PubSub Sidebar[2] since all that is displayed in
the Sidebar is the title of the entry and the feed as well as links to the
entry and feed. We assume that entries have links. You just click on the
interesting item in the Sidebar and your browser will display the content
linked to by the entry.

The same problem exists for the LinkStacks that we offer at MyStack.com.

It should also be noted that Gush[4], in their support for our Atom over
XMPP service, gives users the choice of subscribing to "full content"
entries or just the metadata.

All of these would have to change if entries can't be assumed to have links.
Either we'd have to filter out entries with no links or we'd have to create
local cached copies (very unpleasant), or we'd have to point people to the
source feeds instead (very messy). An elegant solution is not obvious.

		bob wyman

[1] http://www.pubsub.com/developers.php
[2] http://www.pubsub.com/sidebar
[3] http://mystack.com
[4] http://2entwine.com/features/pubsub.html

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 29 Aug 2004 20:01:07 -0700 (PDT)

But you already have this problem with RSS feeds that
have items without links don't you? 

=====

---

From: Mark Pilgrim <[email-masked]>
Date: Sun, 29 Aug 2004 23:39:59 -0400

> section 14.2.1 of the HTML 4.01 Recommendation. I am as surprised that

From section 14.2.1 of the HTML 4.01 Recommendation:

"""User agents should determine the default style sheet language for a
document according to the following steps (highest to lowest
priority):

   1. If any META declarations specify the "Content-Style-Type", the
last one in the character stream determines the default style sheet
language.
   2. Otherwise, if any HTTP headers specify the "Content-Style-Type",
the last one in the character stream determines the default style
sheet language.
   3. Otherwise, the default style sheet language is "text/css".
"""

-- 
Cheers,
-Mark

---

From: Mark Pilgrim <[email-masked]>
Date: Sun, 29 Aug 2004 23:49:12 -0400

> Pilgrim is "that's how it was done in RSS".

Well, I only just now stumbled across this tirade in my killfile, but
I'd be very interested to hear where you think I have said this.  The
last time I checked, Atom entries were standalone items in the
protocol.  They're even root-level elements.

-- 
Cheers,
-Mark

---

From: Robert Sayre <[email-masked]>
Date: Mon, 30 Aug 2004 00:03:03 -0400

> protocol.  They're even root-level elements.

I think Dare was using "standalone" to indicate entries with no 
"alternate" representation, as opposed to entries as "secondary" resources:

'The discussion above assumes that Atom is intended to provide what
"Rich Site Summary" was trying to do. That is, the Atom entry should 
always be considered the "secondary" item, not the primary. The primary 
item is something that the Atom entry talks about, summarizes, or is a 
proxy for.'

http://www.imc.org/atom-syntax/mail-archive/msg09234.html

Robert Sayre

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 30 Aug 2004 08:39:52 +0200

>From section 14.2.1 of the HTML 4.01 Recommendation:

Yes? The relevant part in that section is the sentence after what you
quote,

  Documents that include elements that set the style attribute but
  which don't define a default style sheet language are incorrect.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 30 Aug 2004 09:08:23 +0200

Asbjørn Ulsberg wrote:

> ..
> Content that is provided _only_ because the specification requires it 
> is  garbage. If no human or machine on the planet gains from having the 
> <link>  in the feeds I'm publishing, but the <link> is still provided, 
> it's  garbage.
>  ..

+1

In particular,

- if it's required and often there is no good value value to put in, 
producers will either leave it out or put in gerbage

- for a recipient, it's better to get no value than a value that doesn't 
have the intended semantics; at least it can recover gracefully instead 
of doing something dumb.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Mark Pilgrim <[email-masked]>
Date: Mon, 30 Aug 2004 09:02:39 -0400

>   which don't define a default style sheet language are incorrect.

Aha, so it is.  I'll correct my HTTP headers, thanks.

In the meantime, I have forgotten your original point.  Was it that we
should model Atom interoperability on the ultra-liberal HTML clients
of the world?  Because that is a topic on which I have very strong
opinions.

-- 
Cheers,
-Mark

---

From: Antone Roundy <[email-masked]>
Date: Mon, 30 Aug 2004 09:04:56 -0600

> which can be used to replace those core elements.

A question from one who isn't familiar with many extensions: could I 
get a pointer to the extensions that provide replacements for the 
permalink core elements?  I'd be interested in understanding why 
someone felt the need to make such an extension.

---

From: Antone Roundy <[email-masked]>
Date: Mon, 30 Aug 2004 09:09:44 -0600

> of "alternate" since it is a much more accurate expression of what is
On the other hand, what if the publisher intends for the Atom entry to 
be the "original" and the web page the "alternate".  Or if they don't 
consider any representation to be more "original" than any other--"I'm 
going to publish this data via these 5 different technologies, all at 
the same time."  They're all alternate representations of each other.  
I can imagine that there would be cases where it might be useful to 
know which of the alternatives is the most faithful to the publisher's 
intent, but is the cost of having both "alternate" (which also 
certainly has it's uses--different language versions, for example) and 
"original" worth the benefit?  Maybe so.  I'd have to think on that.

---

From: Danny Ayers <[email-masked]>
Date: Mon, 30 Aug 2004 18:19:01 +0200

I must confess I've only skimmed the recent posts to this thread, but
I still haven't seen any substantial to justify an alternate link
being mandatory.

Ok forget Atom for a second, it seems to me there are three different
cases to look at when describing some syndicated entity. I won't call
them links because it looks to me like whether they resolve or not is
an orthogonal issue.

1. content inline + URI of alternate representations
2. content inline, no URI of alternate representations
3. URI of alternate representations, no content inline

It seems to me to be non-question that all of these should be
supported at entry level. A whole bunch of use cases go out of the
window otherwise.

It's not so obvious at feed level. Presumably 1 would be norm, 3 would
be relatively rare (though I guess reasonable, if there's nothing
sufficiently up-to-date to be worth including in the feed).

In my opinion 2 should be supported for the sake of entirely
transitory feeds - status reports and the like. Making an alternate
link mandatory begs the question of what URI to use. That question
goes away if you specify that no alternate link element means there is
no alternate. But then would empty elements be better ? After all, the
validator has to do something...

So a question, the answer to which might help here (once turned around) - 

Looking at both feed and entry level  situations, how should "there is
no inline content" be expressed?

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Graham <[email-masked]>
Date: Mon, 30 Aug 2004 10:31:09 -0700

Let's pretend for a minute that the spec said alternate links were 
optional (or said nothing, like it does the other link types). To chase 
this you'd need some core use case at the other end that couldn't cope 
with receiving an entry with no link. And there isn't one.

Secodnly, even if 99% of publishers can supply an element, that's 
absolutely no reason to make it mandatory. You only make something 
mandatory when there's real stuff at the other end that can't function 
properly without it.

Thirdly, the argument that if a core element is optional people will 
put the information in an extension element is the most insane thing I 
heard all day (actually I heard it yesterday, but it's taken me since 
then to come to terms with someone actually thinking that).

Graham

---

From: "Roger B." <[email-masked]>
Date: Tue, 31 Aug 2004 00:00:41 -0500

> have the intended semantics; at least it can recover gracefully instead

Julian: Agreed. If Atom didn't have an <id>, then a mandatory permalink
would be a baseline requirement... it would need to do double duty as both
link and poor man's identifier. 

As it stands, a missing alt link has no impact on me at all... so if people
feel that strongly about it, I say ditch the MUST. Or follow Bob's
suggestion and include language that says something like: "If a 'source'
form of the entry exists at a fixed, permanent location, <link
rel="alternate"> MUST be included."

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 31 Aug 2004 08:18:45 +0200

On Sun, 29 Aug 2004 22:16:14 -0400, Robert Sayre <[email-masked]>  
wrote:

> times.

What precedent are you looking for, and for what reason? Why aren't (imho,  
compelling) use cases good enough reason, and why do you always ignore the  
use cases mentioned when they are?

Can you please take one of them at a time, and explain how it should be  
possible to syndicate the following in Atom, and what alternative link  
each scenario should have:

   - Event log monitoring[1]
   - Atom as an e-mail protocol[2]
   - USENET articles that aren't indexed by Google
   - My private CD collection
   - Non-archived mailing lists
   - News events of a football match
   - TV listings
   - «Last played» lists for radio
   - «Next 10» lists for radio

If you can come up with good alternate URI's for all of the above use  
cases, it would probably be okay to require it. If not, then make it  
optional.

____
[1] <url: http://www.rassoc.com/gregr/weblog/archive.aspx?post=570>
[2] <url: http://www.iupload.com/product/mailbyrss.asp>

---

From: Toru Marumoto <[email-masked]>
Date: Tue, 31 Aug 2004 16:38:36 +0900

Hello, 
May I present my ideas?

>  - Atom as an e-mail protocol[2]
e-mail protocol?
>[2] <url: http://www.iupload.com/product/mailbyrss.asp>
I don't think they use RSS as e-mail protocol.
If you do want e-mail protocol, create one or use existing protocol.

>  - USENET articles that aren't indexed by Google
same as Non-archived mailing lists.

> - My private CD collection
You can create a list of CDs in HTML and put it online and use it for alt link. 
It takes ... maybe 10 minutes to create a such page?
Or just create a blog(using MT or whatever) and write an entry for each CDs.

> - Non-archived mailing lists
Redirect mails to MovableType (or something). It generates RSS and Atom. 
(example: [Blog ML Archiver] http://www.dropcontrol.com/~blogml/ml/) (in Japanese)

>   - News events of a football match
someting like RSSCalendar? http://www.rsscalendar.com/rss/
It's got a link.
...
....

Cheers,
Toru Marumoto

---

From: Janne Jalkanen <[email-masked]>
Date: Tue, 31 Aug 2004 16:32:00 +0300

> web resources for which Universal Resource Identifiers can not be 

Well, in the end it does not matter, because those people who cannot 
provide URIs will just provide the system with dummy URIs (like 
http://www.example.com/nothing_here), if the alternate URIs are a 
MUST...  Or they'll just make non-standard conformant Atom feeds and 
assume aggregators will read them - after all, *their* particular 
aggregator happens to read them okay.

(Don't shoot the messenger, that's just what going to happen... :-)

My point being - I see no reason why alternate links are a must.

Obviously, if Atom is defined to be all about syndication of web 
content, then there cannot be any web resources where URIs cannot be 
provided - otherwise they could not be a part of the web, duh.

However, I do see significant uses for Atom as a content delivery system 
as well.  RSS and syndication do have a potential to combine all 
different methods of "delayed communication" into something that can be 
seen with a single, uniform view.  For example, I would love to receive 
on my mobile phone my emails as an aggregate feed (or perhaps just the 
first few lines), the most recent error entries from my UNIX server's 
syslog, the few weblogs I follow regularly, the latest local news 
headlines that have been personalized for me, the latest changes from my 
wiki, as well as some selected advertisements on products I'm thinking 
of buying.

Not all of it requires a web presence.  I see Atom having great 
potential not only for content notification, but also for content 
delivery.  Especially microcontent delivery.  For example, I see 
business potential for mobile operators to provide syndication feeds 
with their own microcontent to their own subscribers.  And as you well 
know, surfing the web on a mobile phone is only slightly less painful 
than having your teeth removed - therefore there is considerable value 
in delivering the content directly to the mobile devices themselves.

Just my 0.03 euro (inflation, you see).

/Janne

---

From: "Roger B." <[email-masked]>
Date: Mon, 30 Aug 2004 22:24:15 -0500

> then to come to terms with someone actually thinking that).

Graham: I dunno... <pubDate> and <dc:date> indicate that people *will* do
exactly that if the core element is optional and there's something even
mildly more appealing about an extension.

Is that a good enough reason to make the core element mandatory? Perhaps
not... but it's clearly far from insane.

---

From: Robert Sayre <[email-masked]>
Date: Tue, 31 Aug 2004 10:17:03 -0400

Asbjørn Ulsberg wrote:

> What precedent are you looking for, and for what reason? Why aren't 
> (imho,  compelling) use cases good enough reason, 

Use cases are fine. It doesn't mean what you're advocating is the right
answer.

> and why do you always 
> ignore the  use cases mentioned when they are?
> 

This is easy. I don't think Atom will be harmed if none of the following 
are possible to syndicate.

>   - «Next 10» lists for radio

Also not convincing: arguments about "flexibility and generality".

Anyway, I gave you the +1, so I'm surprised I'm on the receiving end of 
a flame this morning. I *changed my mind*. That's how consensus happens. 
Try it sometime.

Robert Sayre

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 31 Aug 2004 22:55:27 +0200

>>  - Atom as an e-mail protocol[2]

Yes. «Protocol» is probably not very correct, but there are lots of ideas  
around creating XML feeds as a channel to speak directly to an intended  
audience instead of sending messages with SMTP at the receiver's cost.

I'm not going to hash out all the itsy details about this idea in this  
thread now, but it should be imaginable for everyone that this idea is  
both feasible and possibly an interesting idea.

> I don't think they use RSS as e-mail protocol.

Protocol, schmotocol. The point is that you access an RSS feed to download  
your e-mail instead of having it pushed to you via SMTP and downloaded  
with POP3 or IMAP.

> If you do want e-mail protocol, create one or use existing protocol.

Bah. The point here is that Atom can be used for e-mail. Can you please  
just try to spin your head around that idea, and instead try to think  
constructively about how we can achieve it, and not to mention the subject  
of topic: what URI we put into the <link> element when Atom is used for  
this purpose?

> You can create a list of CDs in HTML

Extra work. Extra _needless_ work. Why is this needed? Who gains from this?

> and put it online and use it for alt link.

So, creating HTML alternatives for every resource imaginable is the  
solution to everything? If so, that should be stated in the specification:

   To be able to publish anything with Atom, you need to create
   an alternative HTML representation of all the resources you're
   publishing, unless the resources are HTML documents.

> It takes ... maybe 10 minutes to create a such page?

Maybe, but who is it for?

> Redirect mails to MovableType (or something).

Movable Type can't solve everything. Or is Movable Type or any other blog  
system an integral part of Atom to make Atom work?

> someting like RSSCalendar? http://www.rsscalendar.com/rss/

I haven't seen RSS calendar's source. What does the <link> point to?

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 31 Aug 2004 22:57:51 +0200

> Use cases are fine. It doesn't mean what you're advocating is the right

It might not, no. But if the use cases are compelling, and there is  
absolutely no reason to not support them, I don't see why we shouldn't.

>> and why do you always ignore the  use cases mentioned when they are?
>

Well, I guess RSS 2.0 will be used instead, since it doesn't require  
alternates.

> Anyway, I gave you the +1

Sorry, but when did you? Either I've forgotten, or I didn't notice. Either  
way, I apologize for that.