Subject: FormatTests

From: Sam Ruby <[email-masked]>
Date: Mon, 11 Jul 2005 16:10:24 -0400

http://www.intertwingly.net/wiki/pie/FormatTests

I've taken a pass at enumerating the test cases required to validate 
Atom 1.0, based on the presumption that things are not going to change 
too drastically from draft-ietf-atompub-format-09.

Undoubtedly there are typos, bugs, omissions, and there might even be an 
occasion or two where I have been overzealous.

My experience has been that this is only a starter set at best, as the 
set of possible errors that people will attempt is well beyond anything 
that one can possibly anticipate.

Corrections welcome.

- Sam Ruby

---

From: James M Snell <[email-masked]>
Date: Mon, 11 Jul 2005 16:29:58 -0700

While we're waiting for more feedback on the format spec, I've been 
stewing over a number of extension ideas.... whatcha think?

The first is rather simple.  It defines an expires element that can be 
applied to a feed or an entry.  I have described the basics @ 
http://www.snellspace.com/wp/?p=174 but am reconsidering that blog 
entries description of how an expires element on the feed interacts with 
an expires element in an entry within the feed.  The element is a Date 
construct that specifies the instant (inclusive) that the entry or feed 
"expires".  This is useful for feeds or entries that contain 
time-sensitive content -- such as special offerings from e-commerce 
sites, "top-ten" lists, etc. 

   <feed>
      ...
      <expires>2005-07-12T12:00:00Z</expires>
      <entry>
         ...
         <expires>2005-07-12T12:00:00Z</expires>
      </entry>
   </feed>

The second extension is a comments link type that allows an entry to be 
associated with a separate feed containing comments.  It is described @ 
http://www.snellspace.com/wp/?p=185.  There is an existing RSS-based 
equivalent already in use described @ 
http://www.sellsbrothers.com/spout/#exposingRssComments.  It would be 
possible to reuse that existing mechanism but it's rather specific to RSS.

   <feed>
      <entry>
         <link rel="comments" href="http://example.com/commentsfeed.xml" />
      </entry>
   </feed>

The third is a non-RDF adaptation of the Creative Commons RSS 1.0 Module 
that uses the Atom link element and provides a machine readable license 
for entries and feeds. It is described @ 
http://www.snellspace.com/wp/?p=184.

   <feed>
      <link rel="license"
           href="http://www.creativecommons.org/licenses/by-nc/1.0"
           xmlns:lic="...">
         <lic:permits>{URI}</lic:permits>
         <lic:requires>{URI}</lic:requires>
      </link>
   </feed>

Thoughts?

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 12 Jul 2005 20:42:42 +0200

* James M Snell <[email-masked]> [2005-07-12 02:00]:
> The second extension is a comments link type that allows an
> entry to be associated with a separate feed containing
> comments. […]
> 
>   <feed>
>      <entry>

What I don’t like about this idea is that if a thread-aware
aggregator wants to keep up with *all* discussion on a weblog, it
will have to poll any number of comments-for-entry-X feeds per
single main newsfeed in the general case – in the case of a
typical weblog encountered in practice, that would be several
hundred. Clearly, this is untenable.

So I would prefer to define an extension element that expresses
“this entry is a comment, posted in reply to the entry with the
atom:id value given herein,” and define a feed-level
atom:link/@rel value that points to such an all-comments feed. A
thread-aware aggregator can then stay updated on any comments
posted anywhere throughout the site by polling a single extra
feed.

Non-thread-aware aggregators can still get some use out of such a
comments feed.

Thinking about it, entirely unaware aggregators would probably
get less out of per-entry feeds than a single unified feed –
they’d need to be subscribed to each entry separately, hugely
cluttering the feedlist.

If you disregard unaware aggregators, you could even serve only a
single feed to aggregators which contains both the actual weblog
posts and their comments.

Thinking about it, there’s no reason you can’t offer both: with
another feed-level atom:link/@rel value you could point
thread-aware aggregators to “the same feed, but with comments
included inline,” so these only need to poll a single feed to
keep up with what’s happening.

Of course, none of these propositions are preclude each other.
Providers may also choose to generate per-entry comment feeds,
but only for a limited amount of new posts, and might want to
expire old per-entry comment feeds by returning 410. This would
be a clear and easy fit in the case of the popular scenario where
old entries get closed against comments to reduce the site’s
linkspamming profile. Or aggregators may choose not to stay aware
of new comments for entries posted long ago.

So I’m not arguing that per-entry comments feeds should in any
way be precluded by the spec, because there’s no reason to do
that. But overall, I think defining an extension element as
outlined above and providing a unified feed of comments for all
entries makes the most sense.

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

---

From: Antone Roundy <[email-masked]>
Date: Tue, 12 Jul 2005 13:10:58 -0600

On Tuesday, July 12, 2005, at 12:42  PM, A. Pagaltzis wrote:
>>         <link rel="comments" 
>> href="http://example.com/commentsfeed.xml" />
>>      </entry>
>>   </feed>
>
If you're already creating an extension link type, why not throw in an 
additional attribute too to help with that:

<feed xmlns:comments="http://example.org/commentfeed">
     <entry>
        <link rel="comments" comments:updated="2005-07-12T12:53:15Z" 
href="http://example.com/commentsfeed.xml" />
     </entry>
</feed>

Then you'd only need to poll the main feed unless it indicated an 
update in the comment feed.  Of course, if comments were threaded, you 
have to cascade comments:updated values up through all the feeds in a 
thread, and aggregators would have to follow updates back the other 
way, potentially down multiple branches, to find all the updated leaves.

...which raises the question of whether an application like this might 
beg a minimal feed for comments that simply pointed to an Entry 
Document for each comment. Entries in such a feed would really only 
require an atom:id, atom:updated, atom:link pointing to the entry 
document, and atom:link pointing to the parent comment or entry. 
atom:title could conceivably be considered undesirable bloat for such a 
feed. Is Atom the right format for this need? An alternative might be 
to define a format for this need that used Atom elements but had 
minimalized cardinality requirements.

Well, enough stream of thought blabbering for now.

---

From: James M Snell <[email-masked]>
Date: Tue, 12 Jul 2005 12:44:02 -0700

Great thoughts... exactly the kind of feedback I was looking for.

What you describe is actually the way we currently integrate comments 
into feeds in the internal IBM blogging infrastructure:  Entries and 
Comments are integrated into a single feed.  Currently there is no way 
of associating (with metadata) a comment to it's entry however.  The 
only connection is that the title of the comment entry uses the "re:" 
naming scheme commonly used for email replies.  If we can come up with a 
way of marking comment entries as comments and providing a meaningful 
link back to the original entry, then this method would definitely be 
workable.

Another alternative would be to follow the model Sam Ruby uses in his 
blog.  That is, produce a single feed for all comments 
(http://www.intertwingly.net/blog/comments.rss2).  The comments link 
could then be included on the feed level rather than the entry level.  A 
single comments feed for a single main entries feed.  The comments feed 
would include the same mechanisms for associating the comment to the 
original entry that we would use in the single feed solution. 

It is entirely possible to use a combination of these approaches.

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 12 Jul 2005 22:14:41 +0200

* Antone Roundy <[email-masked]> [2005-07-12 21:25]:
> If you're already creating an extension link type, why not
> throw in an additional attribute too to help with that:
> 
> Then you'd only need to poll the main feed unless it indicated
> an update in the comment feed.

Note that this makes it impossible to keep up with comments
posted to entries which have slipped off the bottom of the feed.

> Of course, if comments were threaded, you have to cascade
> comments:updated values up through all the feeds in a thread,
> and aggregators would have to follow updates back the other

Ugh. The complexity of implementing this, particularly on the
consumer end with the combination of multiple network fetches and
condition checks intertwined, sounds seriously appaling to me.

> ...which raises the question of whether an application like
> this might beg a minimal feed for comments that simply pointed
> to an Entry Document for each comment. Entries in such a feed
> would really only require an atom:id, atom:updated, atom:link
> pointing to the entry document, and atom:link pointing to the
> parent comment or entry. 

Hmm. I don’t really like this either, because it involves so many
documents. People who produce static files for their feeds would
have to contend with an ocean of piddly Entry Document files.

But it reminded me that atom:link is actually sufficient for what
I said an extension element would be needed in my post – since
atom:id contains a URI anyway, you can just say

    <entry>
        <link rel="in-reply-to" href="{$original-entry/atom:id}" />
        <!-- ... -->
    </entry>

> atom:title could conceivably be considered undesirable bloat
> for such a feed.

I suppose. If you actually inline the comments rather than
pointing to them, though, in the way I outlined, it’s not
undesirable at all. A lot of sites/weblog engines allow including
an (optional or not) title with a comment. And even if not, it
would lend itself to including something like

    <title>Re: <xsl:value-of select="$original-entry/atom:title" /></title>

for the benefit of non-thread-aware aggregators.

> Is Atom the right format for this need? An alternative might be
> to define a format for this need that used Atom elements but
> had minimalized cardinality requirements.

That’s a really drastic measure for such negligible benefit.

One Format To Rule Them All, as far as I’m concerned.

Regards,

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 12 Jul 2005 22:45:34 +0200

* James M Snell <[email-masked]> [2005-07-12 21:55]:
> What you describe is actually the way we currently integrate
> comments into feeds in the internal IBM blogging
> infrastructure:  Entries and Comments are integrated into a
> single feed.

Great to know that there’s precedent for this as well as for the
scenario with a separate feed list (as I mention below).

> Currently there is no way of associating (with metadata) a
> comment to it's entry however.  The only connection is that the
> title of the comment entry uses the "re:" naming scheme
> commonly used for email replies. If we can come up with a way
> of marking comment entries as comments and providing a
> meaningful link back to the original entry, then this method
> would definitely be workable.

As occured to me while replying to Antone Roudy, since atom:id
contains an URI and atom:link/@href must contain an URI, this
could simply be solved with a link included in comments:

    <entry>

That seems to me to a very elegant solution to the issue that
requires minimal work on the Atom parser level to support and
keeps with the spirit of Atom. It’s “Atom-ish”, if you will (en
lieu of the “Perl-ish” that gets thrown around a lot where I come
from :-) ).

> (http://www.intertwingly.net/blog/comments.rss2).

This is actually very common already. I can think of a half dozen
weblogs from my subscription list off the top of my head which
offer such a comments feed.

> The comments link could then be included on the feed level
> rather than the entry level. A single comments feed for a
> single main entries feed. The comments feed would include the
> same mechanisms for associating the comment to the original
> entry that we would use in the single feed solution. 

Yep, exactly. The structure basically suggests itself.

As I said in the previous mail, it might also be worth specifying
a link relation for pointing to a feed with *both* entries and
comments where available, so that a thread-aware aggregator can
switch subscription over to it, only needing to poll a single
feed.

> It is entirely possible to use a combination of these approaches.

Indeed.

I am liking this a lot.

Regards,

---

From: James M Snell <[email-masked]>
Date: Tue, 12 Jul 2005 14:05:37 -0700

Ok, distilled from this conversation...

1. Comments can either be included directly within the feed or in a 
separate feed.
2. Comment entries are distinguished by a link @rel="in-reply-to" 
@href="{$original-entry/atom:id}"
3. Comment feeds may be indicated using a link @rel="comments" 
@href="{$comment-feed-url}" as a child of <feed />

Example 1: Entries and comments in a single feed

<feed>
  <entry>
    <id>http://example.com/2</id>
    <link rel="in-reply-to" href="http://example.com/1" />
    ...
  </entry>
  <entry>
    <id>http://example.com/1</id>
    ...
  </entry>
</feed>

Example 2: Comments in a separate, associated feed

<feed>
  <link rel="comments" href="http://example.com/comments.xml" />
  <entry>
    <id>http://example.com/1</id>
  </entry>
</feed>

<feed>
  <entry>
    <id>http://example.com/2</id>
    <link rel="in-reply-to" href="http://example.com/1" />
    ...
  </entry>
</feed>

The in-reply-to link could also be used in feeds that are not directly 
associated with the source feed.  e.g. if you post an entry in your blog 
and I post a reply to that entry in my blog.  My entry can use the 
in-reply-to link so that thread aware readers can make the connection 
appropriately.

Question: could the @rel="comments" link be handled appropriately using 
the existing @rel="related"?  The question hinges on whether or not it 
is semantically important to distinguish "comments" from other types of 
related entities.  I'm not convinced it is.  If a @link="related" points 
to an Atom feed, who cares what that feed contains, the user agent can 
make the feed available for the user to subscribe to pulling in the 
relevant entries.

- James

---

From: Thomas Broyer <[email-masked]>
Date: Tue, 12 Jul 2005 23:39:38 +0200

> @href="{$original-entry/atom:id}"

As an atom:id is an identifier that might (should?) not be 
"dereferenceable", atom:link is not a good choice. An extension element 
whose content is an URI/IRI (similar to atom:id) would be better:
    <thread:in-reply-to>{$original-entry/atom:id}</thread:in-reply-to>

3. Comment feeds may be indicated using a link @rel="comments" 
@href="{$comment-feed-uri}". If used as a child of atom:feed, it links 
to a feed containing all comments on all entries. If used as a child of 
atom:entry, it links to a feed containing only the comments on the entry.

>    <id>http://example.com/2</id> 

<thread:in-reply-to>http://example.com/1" </thread:in-reply-to>

>    <id>http://example.com/1</id>

<link rel="comments" href="http://example.com/1/comments.xml"
     title="Comments on this entry" />

>    <id>http://example.com/2</id>

<thread:in-reply-to>http://example.com/1</thread:in-reply-to>

> associated with the source feed.  e.g. if you post an entry in your 
> blog and I post a reply to that entry in my blog.  My entry can use 
> the in-reply-to link so that thread aware readers can make the 
> connection appropriately.

Your entry should also link to a representation of the "commented 
resource" using an atom:link[@rel="related"].

And if you're relaying information, you could use an 
atom:link[@rel="via"], as proposed in 
http://www.intertwingly.net/wiki/pie/PaceLinkRelVia

> Question: could the @rel="comments" link be handled appropriately 
> using the existing @rel="related"?  The question hinges on whether or 
> not it is semantically important to distinguish "comments" from other 
> types of related entities.  I'm not convinced it is.  If a 
> @link="related" points to an Atom feed, who cares what that feed 
> contains, the user agent can make the feed available for the user to 
> subscribe to pulling in the relevant entries.

I don't know yet...

-- 
Thomas Broyer

---

From: "Roger B." <[email-masked]>
Date: Tue, 12 Jul 2005 17:53:07 -0500

James: Given that this kind of thing is pretty near-n-dear to me, I'm
quite interested. A couple observations and/or thoughts:

(1) I like this much, much better than the proposed ThreadsML mess of
years past. Simple is good.

(2) Implementation might be a hard sell, so don't get your hopes too
high. wfw:commentRss has been around for years, and RSS Bandit,
Newzcrawler, and (I think) Sharpreader are all on board. But since
more popular feed readers like NetNewsWire and Feeddemon don't support
it, getting individual bloggers to care can be challenging. Which is
kinda silly, since WordPress does per-entry comment feeds out of the
box, but whatcha gonna do?

(3) The link @rel="in-reply-to" @href="{$original-entry/atom:id}"
construct makes sense to me. Particularly since it doesn't just
duplicate wfw:commentRss, which would be kinda pointless.

(4) RE: @rel="comments" vs. @rel="related"
I generally feel like more specific is more better, but I can see
arguments both ways.

--
Roger Benningfield
JournURL

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 13 Jul 2005 02:21:14 +0200

> @href="{$comment-feed-url}" as a child of <feed />

Sounds good to me.

> Example 2: Comments in a separate, associated feed

Yep.

> The in-reply-to link could also be used in feeds that are not
> directly associated with the source feed.  e.g. if you post an
> entry in your blog and I post a reply to that entry in my blog.
> My entry can use the in-reply-to link so that thread aware
> readers can make the connection appropriately.

Hmm. That’s a nice thought that hadn’t occured to me. Thinking
about it, that would offer a way to solve a lot of the mess that
currently plagues the Trackback/Pingback mechanisms. You could
just ping the target weblog with a pointer to the feed which
contains the entry you wrote in response to someone else’s post.

See also below, in reply to Thomas Broyer, on @rel='related'.

It also occurs to me that just like in email (examine the
specimen you’re just reading, f.ex.), there’s nothing that
precludes an entry from having *multiple* @rel='in-reply-to'
links, although in practice this will be rare. Or at least
newsreaders will probably not support it well (like mailers
don’t, even when they thread messages and can send replies to
multiple messages at once – mutt, which I’m sending this message
with, being a fine example), which dooms it to be a rare
situation, anyway. But there’s no particular reason to confine
conversations to trees rather than allowing full directed graphs,
and so long as aggregators are aware that they MAY encounter
multiple backreferences, it’s probably fine for them to do the
same as threading mailers: pick one of the backreferences for the
purpose of threading and ignore the others.

> Question: could the @rel="comments" link be handled
> appropriately using the existing @rel="related"?  The question
> hinges on whether or not it is semantically important to
> distinguish "comments" from other types of related entities.
> I'm not convinced it is.

You have a point… hmm…

@rel='comments' does seem to stem from an arbitrary narrow world
view: it’s kind of stupid unless we are going to specify that the
referenced feed MUST contain ONLY comments – because what if
someone points to a feed which contains unrelated entries? No
harm would be done anyway (most probably, the aggregator would
ignore anything in the purported comment feed that’s not a
comment linked to things in the main feed), but as a description
of the relationship “comments” would be silly.

> If a @link="related" points to an Atom feed, who cares what
> that feed contains, the user agent can make the feed available
> for the user to subscribe to pulling in the relevant entries.

The problem I have with this is that it gives the aggregator a
bit too little to work with. Thread-aware aggregators will
probably want to subscribe a comments feed automatically –
possibly even without user intervention (f.ex. in the case of a
web-based aggregator like Bloglines). But a related feed could be
anything. How does the aggregator know whether it needs to
examine one of these for comments, and if so, which one?

Something more specific than @rel='related' is clearly necessary
to facilitate machine consumption by thread-aware aggregators.

Maybe it should be @rel='has-comments'? Or am I splitting hairs
now?

* Thomas Broyer <[email-masked]> [2005-07-13 00:00]:
> "dereferenceable", atom:link is not a good choice.

There is nothing in the spec that forbids atom:link from being
dereferencable, nor anything that advises against it being so.
See 4.2.6 and 4.2.6.1 in -09.

In fact, Tim Bray has argued that you should go ahead and use
HTTP URIs as IDs:
http://www.tbray.org/ongoing/When/200x/2004/05/28/LinksAndGuids

The spec just says is that the URI MUST NOT be assumed to be
dereferencable, and that the exact value must be considered
opaque: “http://EXAMPLE.COM/foo” is different from
“http://example.com/foo” for the purposes of identifying entries.
Therefore, the spec says, URIs SHOULD be normalized according to
the strategy laid out therein in order to avoid confusion.

That is all.

Whether atom:link is a bad choice for carrying a non-
dereferencable URI around is a better argument. The spec says,
verbatim:

    The "atom:link" element defines a reference from an entry or
    feed to a Web resource.

That would seem to imply dereferencability, but is open to
interpretation. The spec itself goes on to leave matters at the
following:

    The "href" attribute contains the link's IRI. atom:link
    elements MUST have a href attribute, whose value MUST be a
    IRI reference [RFC3987].

That does not mandate any particular interpretation – URIs may be
dereferencable, but don’t have to be.

Personally, I would prefer to interpret the spec liberally, if
that is within the intended spirit, because a new @rel value
requires very little work and seems more likely to gain traction.
Consumers in particular have a large enough burden implementing
threading and threaded display anyway. (For producers, it makes
much less of a difference.)

> @href="{$comment-feed-uri}". If used as a child of atom:feed,
> it links to a feed containing all comments on all entries. If
> used as a child of atom:entry, it links to a feed containing
> only the comments on the entry.

Yep. No reason to pick sides here.

> >The in-reply-to link could also be used in feeds that are not
> >directly associated with the source feed.  e.g. if you post an
> >entry in your blog and I post a reply to that entry in my
> >blog.  My entry can use the in-reply-to link so that thread
> >aware readers can make the connection appropriately.
> 
> Your entry should also link to a representation of the
> "commented resource" using an atom:link[@rel="related"].

I really like this! That would give aggregators the chance to do
something sensible when an entry shows up in a feed which is
in-reply-to an entry in another feed which the particular
aggregator does not subscribe.

Regards,

---

From: James M Snell <[email-masked]>
Date: Tue, 12 Jul 2005 17:44:28 -0700

>See also below, in reply to Thomas Broyer, on @rel='related'.
Yep tho I really don't want to bring trackback/pingback into this 
discussion ;-) This mechanism would make it easier to connect 
conversations on the client without necessarily worrying about server 
infrastructure for trackbacks, pings, etc. 

>purpose of threading and ignore the others.
+1. There's no need to constrain this but I agree that this is 
definitely an edge case

>of the relationship “comments” would be silly.
@rel="related-feed" ???  A bit more specific than "related", the nature 
of the relation is left unspecified.  User agents can choose to handle 
in whatever way they wish.

>Maybe it should be @rel='has-comments'? Or am I splitting hairs
Splitting hairs I think.

>See 4.2.6 and 4.2.6.1 in -09.
This was my interpretation also.  I vote for a liberal interpretation as 
well.

>aggregator does not subscribe.
+1 this is good

- James

---

From: James M Snell <[email-masked]>
Date: Tue, 12 Jul 2005 17:49:39 -0700

>years past. Simple is good.
Absolutely.

>box, but whatcha gonna do?
Evangelism through implementation is all we can do.  Whatever mechanism 
we choose to go with, I'll likely implement support for it in my 
personal blogs WordPress environment and will likely share the code.

>duplicate wfw:commentRss, which would be kinda pointless.
Right.  The goal is to keep it as simple as commentRss while leveraging 
Atom's specific model.  The link element is a natural fit for this.

>I generally feel like more specific is more better, but I can see
I definitely agree that more specific is better.  In a separate note I 
proposed "related-feed" as a possible 
more-specific-than-related-but-not-as-specific-as-comments alternative.  
Whatcha think? Still not specific enough?

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 13 Jul 2005 03:23:30 +0200

* James M Snell <[email-masked]> [2005-07-13 02:55]:
> >about it, that would offer a way to solve a lot of the mess
> >that currently plagues the Trackback/Pingback mechanisms. You
> >could just ping the target weblog with a pointer to the feed
> >which contains the entry you wrote in response to someone
> >else’s post.
> 
> Yep tho I really don't want to bring trackback/pingback into
> this discussion ;-)

I understand the sentiment. :-)  It was idle musing at this
point.

> This mechanism would make it easier to connect conversations on
> the client without necessarily worrying about server

Obviously that’s the primary purpose.

I simply noticed that assuming that the mechanism is in place, it
then becomes be an obvious way to address pings that neatly
avoids the nasty mess in current protocols. But this is something
to deal with in the relatively far future, not now.

> @rel="related-feed" ???  A bit more specific than "related",
> the nature of the relation is left unspecified.  User agents
> can choose to handle in whatever way they wish.

That doesn’t seem to confer more meaning than you can already
express by [@rel='related' and @type='application/atom+xml'].

I think what we want to say is that “aggregators consuming this
feed should consider automatically subscribing to the referenced
feed as well,” which is a much tighter relationship than the
loose “related.”

Maybe “companion?” I don’t know if I like that term, but it’s the
best single-word description I can think of off the top of my
head.

Regards,

---

From: Antone Roundy <[email-masked]>
Date: Tue, 12 Jul 2005 20:09:47 -0600

On Tuesday, July 12, 2005, at 06:21  PM, A. Pagaltzis wrote:
> There is nothing in the spec that forbids atom:link
That should be "atom:id", right?
>  from being
...
> dereferencable,
...
> interpretation.
...
> that is within the intended spirit,
It's definitely not within the spirit that I, for one, intended.  But 
the spirit that I intended (atom:link being limited to links intended 
to be traversed in response to explicit user interaction) was not 
accepted by the WG, so perhaps that has little bearing.

If atom:link is intended to be dereferencable, then clearly, any 
solution that takes a value from atom:id and puts it into 
atom:link/@href has a strike against it since any feed that uses 
non-dereferencable atom:ids would either have to violate the spirit of 
atom:link to participate in the feature, or would have to invent a 
competing solution.

Also, if a feed that uses dereferencable atom:ids is relocated, clients 
would be much more likely to attempt to dereference the atom:links that 
carried those previously dereferencable values than an extension 
element that was explicitly defined as not necessarily dereferencable.

---

From: James M Snell <[email-masked]>
Date: Tue, 12 Jul 2005 21:27:41 -0700

>express by [@rel='related' and @type='application/atom+xml'].
Picky picky ;-)

>best single-word description I can think of off the top of my
I think we could just as easily attach the "you really should 
auto-subscribe" semantic to @rel="related" @type="application/atom+xml" 
without incurring any need for coming up with a new link type.  On a 
conceptual level more-specific is better, but on a practical level, a 
new @rel label doesn't seem to buy us enough benefit to justify 
requiring developers to implement support for it.  @rel="related" feeds 
can simply be handled differently than other @rel="related" stuff.

- James

---

From: James M Snell <[email-masked]>
Date: Tue, 12 Jul 2005 22:18:31 -0700

Antone Roundy wrote:

>
> On Tuesday, July 12, 2005, at 07:23  PM, A. Pagaltzis wrote:
>
>> feed as well,”
> Automating feed subscriptions isn't something that should be done too  
> lightly[1].  The default behavior for an aggregator should be NOT to 
> do  this, and aggregators should give the user the opportunity to 
> control  this feature on a feed-by-feed basis.  Some sort of 
> same-source policy  (like we see with JavaScripts accessing the pages 
> they're loaded into)  might be wise to help prevent abuse, but with 
> lots of feeds getting run  through services like FeedBurner, that 
> would be far from sufficient.
>
> [1]  
> http://www.megginson.com/blogs/quoderat/archives/2005/06/13/the-case- 
> against-easier-feed-subscriptions/
>
>
Ah... good point. Definite room for abuse here.  The user should 
definitely be in control.  However, I don't want to get into dictating 
any particular application behavior.  Rather, we could simply describe 
the issues, the potential for abuse, and offer a number of recommended 
approaches to dealing with it.

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 13 Jul 2005 08:11:45 +0200

* Antone Roundy <[email-masked]> [2005-07-13 04:20]:
> If atom:link is intended to be dereferencable, then clearly,
> any solution that takes a value from atom:id and puts it into
> atom:link/@href has a strike against it since any feed that
> uses non-dereferencable atom:ids would either have to violate
> the spirit of atom:link to participate in the feature, or would
> have to invent a competing solution.

If atom:link is indeed intended to be dereferencable, then my
proposition is bunk and we need an extension element. Even if the
atom:id elements in question carried dereferncable URIs, and thus
could meaningfully be put into atom:link elements, that is beside
the point.

The letter of the spec does not mandate dereferancability right
now.

On whether this is intentional or an oversight, I await judgement
from the WG. Obviously, my own vote is that it’s fine as is: I
see no reason that dictates that atom:link must point to a
concrete Web resource, rather than just an abstract one – neither
conceptually/semantically nor in terms of consequences for
implementation of Atom generators and consumers.

OTOH, if the WG thinks the spec is meant to be stricter than the
letter of the current document, that might be a minor spec bug
that should be fixed in the -10 draft.

(I’m not entirely clear where the minor/major change threshold is
at this stage in the process, and if a fix to this aspect would
violate it. The wording would only require trivial additions; but
the consequences of the change might be considered too major.
Unless maybe it’s argued that this was what the spec said all
along, and this change therefore is just clarification? I don’t
know. Colour me lost.)

Regards,

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 13 Jul 2005 08:25:42 +0200

* Antone Roundy <[email-masked]> [2005-07-13 07:05]:
> Automating feed subscriptions isn't something that should be
> done too  lightly[1].  The default behavior for an aggregator
> should be NOT to do  this, and aggregators should give the user
> the opportunity to control  this feature on a feed-by-feed
> basis.

True, but this doesn’t detract from my argument that we need to
be able to signify a tighter relationship than just “related.” An
aggregator might want to offer different UI for comment feeds, in
contrast to merely “related” feeds. Automatic polling of comment
feeds is just one possible behaviour that differentiates the two.
Another might be that the aggregator asks the user on
subscription whether he/she also wants to poll the comment feed,
but draws no particular attention to “related” feeds, and merely
shows them on a feed details pane or some such.

But the basic issue remains one and the same: the aggregator must
somehow be able to tell that some of the linked feeds are highly
relevant, whereas others are merely of tangential interest.

Regards,

---

From: David Powell <[email-masked]>
Date: Wed, 13 Jul 2005 07:35:18 +0100

>          <lic:requires>{URI}</lic:requires>

I might be on my own here, but I would advise against extending the
link element in this way. I'd say that it is better to use a
Structured Extension Element. The section 6.4 Metadata Elements,
(particularly Simple Extension Elements, though that might not work in
well in this case), are designed so that metadata can be added to
entries without requiring every step in the chain to be upgraded, from
the publishing client, to the XML processor and database of the server
and aggregator.

Because the content of atom:link is undefined, there is a risk that
some implementations, particularly Atom server implementations
accepting entries from a publishing client, might just drop the
contents of the element.

-- 
Dave

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 13 Jul 2005 09:07:49 +0200

* James M Snell <[email-masked]> [2005-07-13 06:40]:
> >Maybe “companion?” I don’t know if I like that term, but it’s
> >the best single-word description I can think of off the top of
> >my head.
>>
> auto-subscribe" semantic to @rel="related"
> @type="application/atom+xml" without incurring any need for
> coming up with a new link type.

That hinges on our respective interpretations of “related.” Is it
expected that feeds will link to “related” feeds which are *not*
tightly associated with the feed in question? Does there need to
be a way for them to do that?

If so, then it follows that “related” is the wrong vehicle for
this purpose.

My opinion is yes, and yes, and hence that is is the wrong
vehicle, which leads me to argue for another relationship type.

> On a conceptual level more-specific is better, but on a
> practical level, a new @rel label doesn't seem to buy us enough
> benefit to justify requiring developers to implement support
> for it. @rel="related" feeds can simply be handled differently
> than other @rel="related" stuff.

Hmm. The argument is good, but the premise mistaken.

Developers will first and foremost have to support the concept of
“highly relevant related feed that should probably be polled in
addition.” It doesn’t matter what relationship type that’s tied
to – it’s implementing the behaviour that takes the bulk of the
work. And this behaviour is not in the core spec to begin with,
so an implementor who has chosen to implement it has done so
consciously enough that they will know about a new relationship
type required for it, and will not be deterred by it.

The choice of relationship to tie this behaviour to is but a
trivial detail that boils down to comparing to a different string
literal in one or at best three or four locations in the
codebase. Special-casing [@rel='related' and
@type='application/atom+xml'] does not seem to be any simpler to
implement than keeping an eye out for @rel='companion'.

So by all I can tell, overloading “related” for this purpose only
muddies the waters semantically such that loosely related
extraneous feeds cannot be distinguished from highly relevant
ones – without offering any actaul simplicity at all in return.

Regards,

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 13 Jul 2005 09:17:33 +0200

* A. Pagaltzis <[email-masked]> [2005-07-13 08:11]:
> Obviously, my own vote is that it’s fine as is: I see no reason
> that dictates that atom:link must point to a concrete Web
> resource, rather than just an abstract one – neither

I should clarify that I defer this to the particular relationship
type. In an atom:link[@rel='alternate'], I do absolutely expect
the @href to be dereferencable. What I don’t see any reason for
is to mandate that @href must always be dereferencable,
regardless of whether the semantics of the type in @rel would
require that or not.

Regards,

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 13 Jul 2005 09:13:19 +0200

* David Powell <[email-masked]> [2005-07-13 08:45]:
> Because the content of atom:link is undefined, there is a risk
> that some implementations, particularly Atom server
> implementations accepting entries from a publishing client,
> might just drop the contents of the element.

We had a discussion recently about this very aspect of the spec,
which concluded that there is no reason that extension elements
would be disallowed inside atom:link. So per the spec, consumers
should expect that extension elements may appear inside
atom:link.

I do agree that a Simple Extension Element (or several) would be
the logical choice for this particular use case, as they offer
defined semantics for attaching metadata directly to an entry.

Regards,

---

From: Antone Roundy <[email-masked]>
Date: Tue, 12 Jul 2005 22:52:54 -0600

Automating feed subscriptions isn't something that should be done too  
lightly[1].  The default behavior for an aggregator should be NOT to do  
this, and aggregators should give the user the opportunity to control  
this feature on a feed-by-feed basis.  Some sort of same-source policy  
(like we see with JavaScripts accessing the pages they're loaded into)  
might be wise to help prevent abuse, but with lots of feeds getting run  
through services like FeedBurner, that would be far from sufficient.

[1]

---

From: Antone Roundy <[email-masked]>
Date: Wed, 13 Jul 2005 07:38:18 -0600

> subscription whether he/she also wants to poll the comment feed,
There's an implementation detail that should be pointed out, in case it 
might influence the language ultimately chosen to define this feature.  
Consider a real world example: I'm subscribed to Slashdot's feed.  If 
they had a comments feed for each story, I would NOT want to subscribe 
to all of them...in fact, with Slashdot's volume, I'd never want to 
subscribe to comments, even if they had a separate feed for each entry. 
  Okay, bad example.

Imagine a hypothetical feed with low enough volume that one might wish 
to subscribe to the comments on some of the main entries, but enough 
volume that one might not wish to subscribe to all comments.  Deciding 
whether to subscribe to comments at the feed level would not be 
sufficient granularity. The user might want the option to subscribe to 
comments on an entry-by-entry basis.  If all of the comments are in a 
single comments feed, then an application supporting this would need to 
be able to track which threads within that feed the user had expressed 
the wish to see.  I'm not saying that's a bad idea--a feed that 
occasionally gets a comment or two on one of its entries would likely 
want to use a one comments feed for all entries approach--just pointing 
it out.  In fact, an application that could do that could go a step 
further and allow the user to stop following specific threads within 
the comments for a particular entry.

So here are the options a user might need:
Application level:
	* Don't subscribe to all comments feeds (default)
	* Subscribe to all comments feeds (DANGER! Beware of things that go 
bump in the night!)

Feed level:
	* Don't subscribe to all comments in this feed (default)
	* Subscribe to all comments in this feed

Entry level:
	* Don't subscribe to comments on this entry (default)
	* Subscribe to comments on this entry

Comment level:
	* Show this thread (default)
	* Don't show anything more in this thread

Turning a higher level option on turns lower ones on, but shouldn't 
take away the ability to turn them off.

---

From: Eric Scheid <[email-masked]>
Date: Wed, 13 Jul 2005 23:50:36 +1000

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

> True, but this doesn¹t detract from my argument that we need to
> be able to signify a tighter relationship than just ³related.² An
> contrast to merely ³related² feeds. Automatic polling of comment

An example that comes to mind of different kinds of feeds: say I have a
pod-cast with a horkin' mp3 enclosure ... and a link to an Atom Feed
Document that contains section by section summaries, complete with some kind
of link to the time-point in the mp3.

That particular Atom Feed Document would never grow, normally, and thus
should not be polled. A user might choose to refresh or reload that Atom
Feed Document, just in case some errors were updated (just as we do with
regular web-pages), but there wouldn't need to be any reason to *poll*.

There are probably many other whole->part feed document scenarios.

Quick poll: how many feed readers let the user read the current feed
document without first requiring them to subscribe. That is, present the
content, along with a button "subscribe to future updates".

e.

---

From: Eric Scheid <[email-masked]>
Date: Thu, 14 Jul 2005 00:20:47 +1000

On 13/7/05 5:17 PM, "A. Pagaltzis" <[email-masked]> wrote:

> the @href to be dereferencable. What I don¹t see any reason for

I've been thinking .. the attribute is @href, not @uri. That¹s Hypertext
REFerence, not Universal Resource Identifier. Ignoring the process for a
moment ... could we have @href and then also @idref ... then when we mean to
provide a dereferenceable uri we can put it in @href, and when we want to
provide an ID reference we can put it in @idref. We can even put both into a
link, and if the @href returns a 404 or otherwise indicate it is not the
thing being sought, then we could try querying an ID resolver to find the
new location.

e.

---

From: Graham <[email-masked]>
Date: Fri, 15 Jul 2005 21:00:39 +0100

Why does the validator apparently fail outright when SHOULD level  
requirements are ignored? This seems unnecessary in light of having a  
spec where conformance levels are clearly defined.

Graham

---

From: Sam Ruby <[email-masked]>
Date: Fri, 15 Jul 2005 18:20:04 -0400

> spec where conformance levels are clearly defined.

Can you be more specific?

Perhaps this will help: FormatTests documents my intent.  If you see 
something there that is wrong, by all means, go fix it.

What you see with the current validator in terms of Atom 1.0 support is 
what I was able to cobble together on a plane ride out; and I'm taking a 
red-eye back tonight.

I expect this to be rapidly corrected over the next few days.

When I feel that the feedvalidator is anywhere near ready to be 
considered seriously for Atom 1.0 feeds, I'll post something on my weblog.

- Sam Ruby

---

From: Graham <[email-masked]>
Date: Sat, 16 Jul 2005 11:27:45 +0100

> Can you be more specific?

If I plug my new Atom 1.0 feed into the validator:
http://www.feedvalidator.org/check.cgi?url=http%3A%2F% 
2Fwww.fondantfancies.com%2Fblog%2Fatom1%2F

Last night, it said the feed wasn't valid, but today it's saying:
"Warning: This feed is valid, but may cause problems for some users.  
We recommend fixing these problems."

I'm not sure about this wording, but providing a warning is fine.

Also:
"Solution: Use the canonical form, given in the warning message."

Are you advocating changing permanent identifiers? Bad Sam.

ID canonicalization was a bloody stupid idea.

Graham

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sat, 16 Jul 2005 17:55:49 +0200

> ID canonicalization was a bloody stupid idea.

Eeep. Even though I don’t think canonicalization was a stupid
idea, more careful thought was and is probably necessary about
the impact it has on things like these.

I suppose the message you got was
http://www.feedvalidator.org/docs/warning/ObscureEncoding.html ?

That would indeed be inappropriate, though a warning should be
given. This needs a warning that strongly cautions against
changing the existing IDs – potentially problematic as they may
be –, but advises that the generation of new IDs should be
adjusted.

Regards,

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sun, 17 Jul 2005 05:42:29 +0200

* Eric Scheid <[email-masked]> [2005-07-13 17:35]:
> Quick poll: how many feed readers let the user read the current
> feed document without first requiring them to subscribe. That
> is, present the content, along with a button "subscribe to
> future updates".

I’ve not seen any dedicated feed readers that do that. The
browsers which know render feeds in a meaningful fashion by
themselves (Safari, Firefox+extension) do allow that.
Unsurprising, really, as feeds have yet to emerge into a lot of
areas outside weblogs or similarly structured content outlets.

Regards,

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sun, 17 Jul 2005 06:14:30 +0200

* Eric Scheid <[email-masked]> [2005-07-13 17:35]:
> could we have @href and then also @idref ... then when we mean
> to provide a dereferenceable uri we can put it in @href, and
> when we want to provide an ID reference we can put it in
> @idref. We can even put both into a link, and if the @href
> returns a 404 or otherwise indicate it is not the thing being
> sought, then we could try querying an ID resolver to find the
> new location.

It would make more sense to me to say that a particular type of
@rel value always expects a dereferencable URI or never expects
on. “in-reply-to” would be in the latter category.

I can see the value in having both for cases where the
relationship may easily be either case. Although I don’t like the
idea of both attributes being present at once; a Link Construct
should refer to one resource, IMHO, and building some kind of
fallback mechanism into it rubs me the wrong way for reasons I
can’t quite verbalize yet.

In which case you could add another attribute to cover this.

Or you could decompose it into two relationship types, both of
which mean the exact same, but of which one expects a
dereferncable URI and the other expects an abstract one.

So as far as I can tell, if we say that @href may contain any
URI, and the semantics of that URI are defined by the value of
@rel, this allows any scenario which @idref would, except for
providing that fallback mechanism.

So, I don’t know… I can see merit in @idref, though I lean
against it.

Regards,

---

From: James M Snell <[email-masked]>
Date: Sat, 16 Jul 2005 21:27:03 -0700

>on. “in-reply-to” would be in the latter category.
+1.  Atom 1.0 does not require link href to be dereferencable.  It 
should fall on the definition of the @rel attribute as to whether or not 
href can actually be dereferenced.

- James

---

From: James M Snell <[email-masked]>
Date: Sat, 16 Jul 2005 22:06:10 -0700

A significant part of my brain is screaming at me that the most logical 
way to associate a license with an entry/feed is to use a link element.  
After all, we are linking the entry/feed with an external resource (the 
license) that is identifiable via URI.  For instance, if I ommitted the 
various permits and requires elements, the following would look very 
natural and straight forward:

  <feed xmlns="http://www.w3.org/2005/Atom">
     ...
     <link rel="license" 
href="http://www.creativecommons.org/licenses/example1" />
  </feed>

It seems that it's only when I introduce the subelements to link that 
things start to appear ugly.

  <feed xmlns="http://www.w3.org/2005/Atom">
     ...
     <link rel="license" 
href="http://www.creativecommons.org/licenses/example1" xmlns:lic="...">
       <lic:permits />
       <lic:requires />
     </link>
  </feed>

At the same time, it is entirely possible for us to make the above link 
compatible with the existing RDF creative commons license by using:

    <link rel="license"
            href="http://www.creativecommons.org/licenses/example1"
            rdf:resource="http://www.creativecommons.org/licenses/example1"
            rdf:type="http://web.resource.org/cc/license"
            xmlns:lic="http://web.resource.org/cc/">
     <lic:permits rdf:resource="..." />
     <lic:requires rdf:resource="..." />
   </link>

The bottom line to this is that it is possible for us to create a 
link-based license attachment for Atom that is backwards compatible with 
the RDF-based Creative Commons module for RSS 1.0. Now, I will say that 
using a specific license element looks nicer (e.g. <license><permits 
/><requires /></license>, etc) but the use of link just seems far too 
logical for it not to be used in this way.

I've implemented a prototype of this in my personal blogs Atom 1.0 
feed.  Unfortunately the Feed Validator does not yet recognize extension 
attributes and elements in link elements as being valid.

http://www.snellspace.com/wp/wp-atom1.php

- James

---

From: Eric Scheid <[email-masked]>
Date: Sun, 17 Jul 2005 15:33:55 +1000

On 17/7/05 2:27 PM, "James M Snell" <[email-masked]> wrote:

>> on. ³in-reply-to² would be in the latter category.
>> 
>>  
>> 

+1

despite this in the spec:

    "The value of "rel" describes the meaning of the link, but does
    not impose any behavioral requirements on implementations"

e.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sun, 17 Jul 2005 10:31:41 +0200

Ugh, I was as clear as mud.

> I can see the value in having both for cases where the
                         ^^^^^^^^^^^ ie defining @idref and @href
> relationship may easily be either case. Although I don’t like
> the idea of both attributes being present at once; a Link
> Construct should refer to one resource, IMHO, and building some
> kind of fallback mechanism into it rubs me the wrong way for
> reasons I can’t quite verbalize yet.
> 
                              
Ie rather than @idref, a boolean attribute that says whether
@href is dereferecable or not.

> Or you could decompose it into two relationship types, both of
                         ^^ referring to this boolean attribute

Regards,

---

From: Graham <[email-masked]>
Date: Sun, 17 Jul 2005 15:45:26 +0100

> "Solution: Use the canonical form, given in the warning message."

It now says:
"All newly issued ids should be in canonical form. Use the canonical  
form given in the warning message for guidance."
(http://feedvalidator.org/docs/warning/NonCanonicalURI.html)

While an improvement, it needs to say that old ids cannot be  
corrected and the old thing you can is prevent it happening in  
future. It might therefore be simpler to not flag this problem at all.

Now do you see why canonical ids are stupid and irrelevant?

Graham

---

From: Walter Underwood <[email-masked]>
Date: Sun, 17 Jul 2005 15:16:23 -0700

> Now do you see why canonical ids are stupid and irrelevant?

Not unless the robustness principal is stupid and irrelevant.
Canonical IDs are more robust. Feeds that use them will work better
in the quick-and-dirty, "Desperate Perl Hacker" environment of the
internet.

The updated warning is just right. Thank you for using Atom, here is
how you can do a better job.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: "A. Pagaltzis" <[email-masked]>
Date: Mon, 18 Jul 2005 01:25:21 +0200

> http://www.feedvalidator.org/docs/warning/ObscureEncoding.html ?

Err, of course not, but now I’m not sure that
http://www.feedvalidator.org/docs/warning/NonCanonicalURI.html
is new or was simply changed.

Regards,

---

From: Graham <[email-masked]>
Date: Mon, 18 Jul 2005 15:18:37 +0100

> in the quick-and-dirty, "Desperate Perl Hacker" environment of the

As long as those intermediaries corrupt IDs in exactly the right way.  
Good luck with that.

Meanwhile, all new postings to my blog will have the ids  
differentiated by varying the capitalization of the hostname, and  
nothing else.

Graham