Subject: Feed Thread in Last Call

From: James M Snell <[email-masked]>
Date: Mon, 15 May 2006 15:15:18 -0700

Hey all,

I'm happy to announce that the Feed Thread extension (draft -10) [1] has
 entered Last Call. [2]

The thr:count and thr:when extension attributes are back in Draft -10
following the recent on-list discussion and post by Tim Bray affirming
that the atom:link element is indeed extensible.  I fully recognize that
not everyone on list agrees with this approach, but after trying to
propertly implement alternatives, re-reading RFC4287 and surveying folks
who I know have already done the work necessary to implement Feed
Thread, I believe the decision to keep thr:when and thr:count as
attributes is the right decision.

At this point, Feed Thread support has been deployed in Friendster,
Typepad, and MovableType.  I have also added Feed Thread support to my
Wordpress and Roller blog templates.  IBM has plans to ship at least one
product with Feed Thread support in the not too distant future (our Atom
Publishing Protocol interop/test endpoint currently contains support for
Feed Thread).

If you do or do not want to see Feed Thread move forward as a Proposed
Standard, now is the time to step up and make your case. :-)

- James

[1]http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-10.txt
[2]https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13577&rfc_flag=0

---

From: "Robert Sayre" <[email-masked]>
Date: Tue, 16 May 2006 04:33:42 +0200

On 5/16/06, James M Snell <[email-masked]> wrote:
> Typepad, and MovableType.

I thought the working group was fairly clear about the dubious value
and placement of these attributes, and you yourself posted that no one
was implementing them, they were "strictly informational", and free to
be ignored. So you don't think they're important or needed, and then
WG doesn't have consensus on them. Even Tim's comments were in the
abstract, and not related to feed thread at all.

You don't have to listen to the WG, but if one or two WG members are
going to deploy and then standardize whatever they've done, that's an
informational document.

From a technical perspective, the interactions between multiple links
with the extension attributes remain unspecified. As a client
implementor, I suppose I'll find out what exactly they're for whenever
I see the already-completed implementations deployed. In my opinion,
the document should do more to inform the community on the role of
these attributes.

> now is the time to step up and make your case.

You've merely stated you "believe" that moving these attributes back
to the original location is the right decision. That is not a
technical rationale. I would expect to see a more compelling reason,
given the clear, technical rationales of those against your decision.

On an unrelated note, this document contains sections copied verbatim
from RFC 4287, and it would be polite and honest to acknowledge that.

-- 

Robert Sayre

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 16 May 2006 05:45:10 +0200

* Robert Sayre <[email-masked]> [2006-05-16 04:45]:
> […]

+1

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

---

From: James M Snell <[email-masked]>
Date: Mon, 15 May 2006 20:50:03 -0700

> I thought the working group was fairly clear about the dubious value

A few of the individuals on the WG had a problem with the placement of
the attributes due to various limitations of a few existing Atom 1.0
implementations. None of the folks I know of that have actually
implemented support for the extension has had any problems with them.

> abstract, and not related to feed thread at all.

I never posted that no one was implementing the attributes. Quite on the
contrary, you can pull up quite a few TypePad and Friendster feeds that
are using them.  You can also look at Sam Ruby's personal blog... or
look at my wordpress and roller blog feeds.  The attributes are being used.

What I did say was that I wasn't aware of anyone using multiple replies
links in a single entry and that I personally did not intend on
publishing any feeds that used multiple replies links in a single entry.

> the document should do more to inform the community on the role of

The interaction is unspecified because there is no interaction.  As I've
said before, the thr:count and thr:when attributes apply only to the
atom:link element to which they belong.

The slash:comments extension element can be used to provide a global
comment count that operates independently of the replies link.

The roles of the attributes are clearly specified in the spec.  There
are existing feeds in deployment that demonstrate their use.
.
> from RFC 4287, and it would be polite and honest to acknowledge that.

My apologies, I thought I had already done so.  It will be fixed in the
next revision.

- James

---

From: "Robert Sayre" <[email-masked]>
Date: Tue, 16 May 2006 07:22:23 +0200

On 5/16/06, James M Snell <[email-masked]> wrote:
> implementations.

Right, and you're breaking them because...? You haven't coherently
explained your reason for moving them back. After all, you agreed with
the WG and updated the document, but now you've moved them back for
unexplained reasons and pointed at deployments.

> None of the folks I know of that have actually

I find your answers most unsatisfying and full of circular reasoning
that serves mostly to dance around the fact that you and a few others
have already deployed. That's been your argument for months now, and
the IETF process has a way to deal with that situation: Informational.

-- 

Robert Sayre

---

From: James M Snell <[email-masked]>
Date: Mon, 15 May 2006 22:49:50 -0700

> unexplained reasons and pointed at deployments.

Very simple reasons: the attributes are easier to implement, are allowed
by RFC4287 and are being used in real deployments.  That's more than
enough justification for me.

I agreed in principle with the arguments presented by David and
Aristotle; Accordingly, I drafted up an alternative; Implemented the
alternative; Compared the two implementations and the pros/cons of each;
Discussed those on the mailing list; and decided in the end that the
risk/benefit weighed in favor of the attributes.

After testing a number of Atom implementations, I have yet to find one
that is "broken" as a result of using the attributes.

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 16 May 2006 08:00:56 +0200

* James M Snell <[email-masked]> [2006-05-16 06:00]:
> The slash:comments extension element can be used to provide a
> global comment count that operates independently of the replies
> link.

Supply per-link information as namespaced attributes on link
elements, if you must. I don’t like the idea, but it seems there
is unfortunately no way to associate link-specific RFC 4287
Simple or Structured Extension Elements with a link. (But why
`thr:when` rather than `thr:updated`?)

However, don’t neglect to provide a way to supply a global reply
count. That would break the argument that the FTE covers nearly
every threading use cases without having to resort to a gaggle of
other extensions and hence weaken FTE’s position, IMO.

Regards,

---

From: "Robert Sayre" <[email-masked]>
Date: Tue, 16 May 2006 08:11:46 +0200

On 5/16/06, James M Snell <[email-masked]> wrote:
>
> Very simple reasons: the attributes are easier to implement,

Speaking as an actual, rather than alleged, client implementer, I find
this assertion ridiculous and dishonest.

> are allowed by RFC4287 and are being used in real deployments.

So, the argument is that it's already deployed, then? It looks like
you agree with me.

-- 

Robert Sayre

---

From: James M Snell <[email-masked]>
Date: Mon, 15 May 2006 23:18:07 -0700

> `thr:when` rather than `thr:updated`?)

RFC4287 does not forbid simple or structured extension elements on link.

> other extensions and hence weaken FTE’s position, IMO.

I will consider adding a thr:count element to the spec to cover the
global count case.

- James

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 16 May 2006 14:39:58 -0700

At 4:33 AM +0200 5/16/06, Robert Sayre wrote:
>and placement of these attributes,

For the benefit of Lisa, who is the sponsoring AD for this document, 
please list links to those messages.

>So you don't think they're important or needed, and then
>WG doesn't have consensus on them.

Quite true, but it is true because there has never been a call for 
consensus on the document, and there won't be in the future.

In the IETF, individuals can submit documents to become RFCs without 
those documents being Working Group items. This document (and all of 
the other format extension documents out there) fall into that 
category. If the author asks an Area Director to have the document 
published as a standards-track RFC, the AD will most likely ask for 
input on any relevant mailing list, including any existing WG mailing 
lists.

>going to deploy and then standardize whatever they've done, that's an

That is not true. If it is a protocol or a format, standards track is 
also appropriate.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Robert Sayre" <[email-masked]>
Date: Wed, 17 May 2006 00:03:47 +0200

> please list links to those messages.

James changed the document in response to those messages. That should
be enough. Maybe she could ask James about them. It's not my
obligation to spelunk for them, and it's certainly not your place to
start making demands like that.

> consensus on the document, and there won't be in the future.

Well, I'm not going to quibble with you about procedural details. But
I have to wonder why they're in the document at all.

Looks like the IETF wants to publish a "proposed standard" explicitly
designed to break a very popular implementation, with no technical
reason. I think that speaks volumes about the IETF, its management,
and the quality of its "individual" contributors.

> That is not true. If it is a protocol or a format, standards track is

Well, I don't want to standardize some of what James has deployed. It
won't work in Sean's implementation. I'm not sure I can interoperably
implement the parts in question. Your two biggest client implementers
aren't real happy about this. It might be appropriate if you really
stretch, but it's sure not smart.

-- 

Robert Sayre

---

From: James M Snell <[email-masked]>
Date: Tue, 16 May 2006 15:55:57 -0700

Robert Sayre wrote:
>[snip]

"...explicitly designed to break a very popular implementation"!?  Give
me a break.  I've been purposefully judicious lately not to respond to
crap like this but given the Last Call status on the spec, I think
several very clear points need to be made:

1. My decision to use the attributes has absolutely nothing to do with
Microsoft's implementation.  In fact, the attributes were introduced to
the spec *before* I knew any details about the Microsoft implementation.
Any claims to the contrary are false.  Any claims that I *explicitly
designed* the extension to break a particular vendor implementation
borders on the downright absurd.

2. Microsoft's implementation is no more "broken" by the use of the
attributes than any other feed reader implementation that has not been
specifically modified to support the extensions.  I use Liferea, it
can't do anything with the thr:count or thr:when attributes either.  I
guess that means I "exlicitly designed" the spec to break Liferea as
well?  Microsoft's implementation doesn't support multiple enclosures,
so I guess RFC4287 was "explicitly designed" to break their
implementation? Please, enough.

I asked Byrne Reese if he could load up Sam Ruby's personal blog feed in
IE7 and capture a screenshot.  Sam's feed uses the thr:count and
thr:when attributes.  IE7 worked as expected, properly ignoring the
extensions it does not understand.

  http://www.snellspace.com/public/ie7screen.png

What's broken?

- James

---

From: "Robert Sayre" <[email-masked]>
Date: Wed, 17 May 2006 01:38:07 +0200

> What's broken?

Do you think the AD and this WG are dumb? Why are you setting up such
an obvious strawman?

Congratulations, your extension didn't break Atom. The point is that
your extension is broken. You're including attributes in that document
that you know won't be visible to a large number of implementations.
You have no technical reason that makes that location compelling, and
several WG members have questioned whether this document adequately
covers the area in question. In fact, you appear unable to explain the
rationale behind any technical decision without resorting to circular
reasoning, logical fallacies, and claims that are outright false.

-- 

Robert Sayre

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 17 May 2006 02:14:38 +0200

* Robert Sayre <[email-masked]> [2006-05-17 01:50]:
> You have no technical reason that makes that location
> compelling, and several WG members have questioned whether this
> document adequately covers the area in question.

I have to disagree that there is no technical reason.

There is no way to sanely associate additional information with a
link element. I suggested an approach based on cross-referencing
with the `href` value, but interactions with xml:base invalidate
that approach. Other than `href`, there is no other hook on
`atom:link` which could be used for cross-referencing without
resorting to microparsing hacks.

The root of the problem is a miniscule omission in RFC 4287: Sec
6.4. does not list `atom:link` as a location for Metadata
elements. It should have. The effect is that links in Atom can
only be extended at the XML level, not at the model level.

There is no other reasonable choice for the FTE than to supply
this information as namespaced attributes on the link element.
This is now clear.

I hate the idea as much as you do, but RFC 4287 is what it is.

> In fact, you appear unable to explain the rationale behind any
> technical decision without resorting to circular reasoning,
> logical fallacies, and claims that are outright false.

That doesn’t mean there is *no* reason for any of these technical
decisions.

But I agree that James has advocated the position he chose on
this particular issue extremely poorly, just as you’d have done
your own argument a favour by omitting your interpretation of the
matter as vendor politics.

Regards,

---

From: "Robert Sayre" <[email-masked]>
Date: Wed, 17 May 2006 02:46:05 +0200

On 5/17/06, A. Pagaltzis <[email-masked]> wrote:
> link element.

Sure there is, and it's the way James did it. Is the information
valuable? Does the spec cover cardinality issues? Is the link element
useful here? Was the spec less effective in its previous incarnation?
The answer to all of these questions is no.

-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

---

From: "Robert Sayre" <[email-masked]>
Date: Wed, 17 May 2006 03:23:36 +0200

On 5/17/06, Lisa Dusseault <[email-masked]> wrote:
>
>   - We're talking about visibility to implementations of the base
> spec only, not implementations of the extension, naturally.  Any new
> information can be visible to implementations of that extension.

There's a misunderstanding here. Many applications rely on a feed
parsing service provided by the OS or a language-level library. Some
of those platforms (MS is not the only one) don't provide access to
extension attributes on the link element. For example,

<entry>
...
<foo:bar />
<link foo:bar="baz" ... />
</entry>

here the extension attribute stands a chance of getting lost. The
reason this occurs is because it's much easier to design an API that
doesn't deal with these things in the general case. This situation
could change in the future, as Atom consumer APIs develop.

My implementation will parse and preserve the attribute, but I'm not
sure what I'm supposed to do with it at an application level,
especially if I encounter more than one such link element.

As a result, I see no reason to introduce gratuitous compatibility
problems when the cardinality of the link element doesn't seem to suit
the problem very well.

>   - We're talking about adding machine-parsable data that would be
> invisible to readers of the post content

I don't know. The specification says nothing about that. Presumably,
the implementers that have already deployed know what they are for.

-- 

Robert Sayre

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 16 May 2006 18:00:55 -0700

On May 16, 2006, at 4:38 PM, Robert Sayre wrote:

>  You're including attributes in that document

Is there some way that one could write an Atom extension that would  
have new feed/post information that *would* be visible to a large  
number of implementations?

Some assumptions I'm making in reading this, so you can correct me if  
my assumptions are wrong:
  - We're talking about visibility to implementations of the base  
spec only, not implementations of the extension, naturally.  Any new  
information can be visible to implementations of that extension.
  - We're talking about adding machine-parsable data that would be  
invisible to readers of the post content

Lisa

---

From: James M Snell <[email-masked]>
Date: Tue, 16 May 2006 18:38:17 -0700

> especially if I encounter more than one such link element.

This will be fixed in the next revision of the draft.  The short answer
is: every "replies" link MUST be processed independently of any others.
  That is, the feed consumer MUST NOT assume that multiple replies links
are all just pointing at different representations of the same set of
responses.

> the implementers that have already deployed know what they are for.

Machine-parseable data that may or may not be presented to users. The
spec is silent on how the metadata should be used because there is no
reason to dictate how it should be used.  Implementations should use it
in whatever way they feel is most appropriate.

- James

---

From: Martin Duerst <[email-masked]>
Date: Wed, 17 May 2006 13:14:59 +0900

Hello Robert,

It's not the IETF which wants to move this on on Standards Track,
it's (currently) James as an individual submitter. The IESG just
did what it does for all such requests from individuals: Put the
document out for IETF Last Call and tell the relevant mailing lists
about it.

Now it's your (and everybody else's) turn to tell the IESG what
you think about this draft. A short, but clearly argued and nicely
worded mail, with some easy-to-follow pointers to further material,
is all that is needed. This may say "okay with Standards Track iff
these things get fixed" or "should be experimental because ..." or
even "too controversial for an individual submission, needs a WG".

The time you invest in this email will be a lot better spent than
writing yet another mail to James and this list.

Lisa (the "sponsoring" AD) and the rest of the IESG will then look
at all the input they get, and will make a decision.

Regards,    Martin.

---

From: "Sylvain Hellegouarch" <[email-masked]>
Date: Wed, 17 May 2006 09:50:24 +0100 (BST)

> in whatever way they feel is most appropriate.

I'm sorry to stir this up again but I've read once more the last FT draft
and I still cannot understand the use of the thr:count and thr:when
attributes. Well in regards to the context they sit I see their meaning
but I cannot see their value.

If a feed containg FTE information is meant to be handled by machines
only, then those values are not precise enough to be use (but I'd be happy
to gearing about them though). If those values are to be presented to
users, they are also not precise to have any interest.

Besides, say a comment is added to the comments feed. I, as an application
developer, will want to update thr:count and thr:when of the entry itself.
Meaning that I will have to disregard any If-Modified-Since header sent by
an aggregator to check out if my entry has changed when it has actually
not changed per se.

Anyway, I do not see the value brought by thr:count and thr:when
alltogether. Since it is a MAY as well, I hardly see the point of keeping
them.

Another point is that neither your draft nor RFC 4287 seem to say what a
processor, which cannot process a value of the rel attribute, should do.
Should the link be ignored? Should an error be raised? I assume the former
but sadly the spec is not helping in this case.

Finally, if I set a <link rel="replies" ... /> into a feed element, should
the ref attribute of the in-reply-to should use the id of the feed or the
entry it concerns? If it is the former, aggregators won't be able to
correlate threads and entries.

- Sylvain

---

From: Eric Scheid <[email-masked]>
Date: Wed, 17 May 2006 21:33:12 +1000

> are all just pointing at different representations of the same set of

would this mean this is possible:

<entry>
    <link rel="replies" thr:count="5" xml:lang="en" href="1" />
    <link rel="replies" thr:count="1" xml:lang="fr" href="1" />
    ...
</entry>

e.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 17 May 2006 14:47:50 +0200

>     <link rel="replies" thr:count="1" xml:lang="fr" href="1" />

You mean `hreflang`, not `xml:lang`, right?

I have to say at first blush I don’t see why it should not work,
so I find your thought experiment quite amusing.

Regards,

---

From: Eric Scheid <[email-masked]>
Date: Wed, 17 May 2006 23:52:16 +1000

> You mean `hreflang`, not `xml:lang`, right?

oops, yes.

> I have to say at first blush I don¹t see why it should not work,

:-)

---

From: James M Snell <[email-masked]>
Date: Wed, 17 May 2006 08:15:47 -0700

> users, they are also not precise to have any interest.

I have no idea what you mean by "not precise enough to be used". What
makes them imprecise?

Look at just about piece of blogging software that accepts comments and
on the front page you'll typically see a link that specifies the number
of comment received for that entry.  It may, or may not be an accurate
count, but it serves a useful purpose. Why is the same metadata not
useful in an entry/feed?

> but sadly the spec is not helping in this case.

The spec is silent on this, handle it however you want to handle it in
your implementation.  IMHO, Good implementations will silently ignore
links they don't understand.

> correlate threads and entries.

The ref attribute is the unique identifier of the resource being
responded to.  It doesn't make make sense to respond to a Feed.

- James

---

From: "Sylvain Hellegouarch" <[email-masked]>
Date: Wed, 17 May 2006 16:36:09 +0100 (BST)

> I have no idea what you mean by "not precise enough to be used". What

The very fact they don't represent a state that can be trusted. As the
spec says they are not the true value but the true value at one given
time.

> count, but it serves a useful purpose. Why is the same metadata not

Well to take your example a bit further. Say I'm following comments posted
to an entry, since there is no way for me to decide if the number provided
by the extension is the most up-to-date, I will have to manually go to the
source itself and check if someone replied since my last visit. How is
that useful to me as an user?

Besides you do not answer the question of HTTP caching I mentionned.
Basically it would break most planets out there which rely heavily on the
'304 Not Modified' status code to check if a feed has been modified. In
this case a server such as Apache would respond: "well yes the file has
changed on the disk so here it is" when in fact the content of the feed
has only changed for the number of comments of an entry.

Clients could of course work around such issue but this is a rather big
problem to me.

> responded to.  It doesn't make make sense to respond to a Feed.

Common sense is one thing, being clearly specified is another one.

- Sylvain

---

From: "Sylvain Hellegouarch" <[email-masked]>
Date: Wed, 17 May 2006 16:40:15 +0100 (BST)

> responded to.  It doesn't make make sense to respond to a Feed.

By the way, don't get me wrong. I am really looking forward to the FTE
replies element but not its attributes which are just useless and counter
productive to my liking.

- Sylvain

---

From: James M Snell <[email-masked]>
Date: Wed, 17 May 2006 09:08:00 -0700

> spec says they are not the true value but the true value at one given

The values are no more or less trustworthy than the link's own type,
length, and hreflang attributes.  I refer you to
http://www.w3.org/2001/tag/doc/mime-respect-20060412

> that useful to me as an user?

If you need an exact count, go to the linked resource. Feed publishers
should take steps to ensure that the count is accurate. Again, read the
W3C Tag finding referenced above.

> has only changed for the number of comments of an entry.

HTTP provides a possible solution to this in the form of a weak entity
tag.  Also, Feed delta encoding could be leveraged to further mitigate
the potential issues.

> Clients could of course work around such issue but this is a rather big

I would suspect that you currently have the same problems with folks
that use the highly popular slash:comments RSS extension. FTE is not
introducing any new problems, nor is it seeking to fix existing problems
in the feed syndication model.

- James

---

From: Eric Scheid <[email-masked]>
Date: Thu, 18 May 2006 02:56:08 +1000

> You mean `hreflang`, not `xml:lang`, right?

I also meant there to be different hrefs too :-(

<entry>
    <link rel="replies" thr:count="5" hreflang="en" href="1" />
    <link rel="replies" thr:count="1" hreflang="fr" href="2" />
    ...
</entry>

e.

---

From: Eric Scheid <[email-masked]>
Date: Thu, 18 May 2006 03:02:08 +1000

On 18/5/06 1:36 AM, "Sylvain Hellegouarch" <[email-masked]> wrote:

> Apache would respond: "well yes the file has

so? 

we have atom:updated to help aggregators detect if there has been a
significant change ... everything else is just meta data.

e.

---

From: Eric Scheid <[email-masked]>
Date: Thu, 18 May 2006 02:57:49 +1000

> so I find your thought experiment quite amusing.

this should be amusing too:

<entry>
    <link rel="replies" thr:count="5" href="1" title="trackbacks!" />
    <link rel="replies" thr:count="1" href="2" title="comments!" />
    ...
</entry>

e.

---

From: James M Snell <[email-masked]>
Date: Wed, 17 May 2006 10:27:50 -0700

Yes. This is possible. What I'm not sure about is whether "amusing" is
"good" or "bad". What point are you trying to make exactly?

- James

---

From: James M Snell <[email-masked]>
Date: Wed, 17 May 2006 10:41:59 -0700

> replies element but not its attributes which are just useless and counter

Can't you just ignore them then?  The feed update / last-modified issue
is not isolated to the use of thr:when and thr:count.  As I mentioned in
another note, you end up with the exact same problem when folks use the
slash:comments element but no one seems to mind that.  This problem is
not unique to FTE, nor does FTE make the problem any worse.

What else, in your opinion makes them useless and counter productive?
I'm seriously asking because I really don't see it.

- James

---

From: "Sylvain Hellegouarch" <[email-masked]>
Date: Wed, 17 May 2006 18:57:49 +0100 (BST)

> I'm seriously asking because I really don't see it.

Well to me there is no need to include, or specify, information that
cannot be found otherwise already.

Specifying the way to find how to retrieve the replies resource is a great
idea and I'm looking forward to it.

However, if I'm an aggregator I don't need the thr:count and thr:when
because I will find those information anyway with the following process:

1. I fetch the comment feed and put it my cache
2. I want to know if a new comment has been posted, I won't fetch the feed
containing the entry but the feed containing the comment
   a. No comment added => 304 Not Modified
   B. A comment added => I fetch the feed again and know both the number
of comments and the date of the latest one

This process will happen anyway from the aggregator point of view so I see
little value in the 'thr' attributes overall.

- Sylvain

---

From: "Sylvain Hellegouarch" <[email-masked]>
Date: Wed, 17 May 2006 18:59:57 +0100 (BST)

> significant change ... everything else is just meta data.

I'm not sure you have understood me. I'm not talking about the application
level but from the HTTP level. If we update the feed each time we update
the thr attributes then we screw the HTTP cache big time and waste
bandwith. If we don't update them to avoid that issue then those
attributes are just useless.

Personally I have no interest in doing either way.

- Sylvain

---

From: "Sylvain Hellegouarch" <[email-masked]>
Date: Wed, 17 May 2006 19:02:34 +0100 (BST)

> tag.  Also, Feed delta encoding could be leveraged to further mitigate

ETag are not reliable without If-Modified-Since header and they are not as
wide spreaded.

> in the feed syndication model.

This is rather sad. So because others are broken we should not do better.

- Sylvain

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 17 May 2006 20:09:05 +0200

> I also meant there to be different hrefs too :-(

Oh! I thought that was the point – the idea being that you can
express (roughly – not precisely) that there are X entries in
SomeLanguage at $some-uri and Y entries in OtherLanguage at the
same $some-uri. Which I think is in fact expressible. But I’d
have to go back and check RFC 4287 in detail to know for sure.

* James M Snell <[email-masked]> [2006-05-17 19:40]:
> What I'm not sure about is whether "amusing" is "good" or
> "bad".

If what you’re asking is what I meant by “amusing,” then the
answer is “good.”

Regards,

---

From: James M Snell <[email-masked]>
Date: Wed, 17 May 2006 11:08:41 -0700

> This is rather sad. So because others are broken we should not do better.

No. I'm only just trying to solve one problem at a time.

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 17 May 2006 20:20:26 +0200

* Sylvain Hellegouarch <[email-masked]> [2006-05-17 20:10]:
> However, if I'm an aggregator I don't need the thr:count and
> thr:when because I will find those information anyway with the
> following process:

Consider the situation where a weblog only has a single global
comments feed – which I strongly favour because having one of
them for each entry just does not scale. Then it’s easily
possible for some comments to have fallen of the bottom of the
comments feed by the time you fetch it to check. In that case,
the information in the attributes will be more accurate than the
process you describe.

Regards,

---

From: James M Snell <[email-masked]>
Date: Wed, 17 May 2006 11:20:37 -0700

> cannot be found otherwise already.

Do you feel the same way about the link element's existing type, title,
hreflang, and length attributes?

> little value in the 'thr' attributes overall.

This boils down to an implementation choice.  The thr attributes provide
a way for UI's to display something before fetching the feed, which is
often useful for an individual to decide whether or not it is even
worthwhile to fetch to the comments feed in the first place.

Also, consider that comment feeds may span multiple pages (using the
paging link rels).  With your algorithm (which, yes, is the only
authoritative way of determining *exactly* how many comments have been
received), you would have to retrieve every page and count up the
comments.  Considering also that feeds do not necessarily have to be
ordered chronologically (tho most are) and that the feed may contain
comments to multiple entries, getting a precise count of the total
number of comments can be a time and resource consuming process that
involves examining every individual entry in the feed for the presence
of a matching in-reply-to link. Alternatively, you could decide to trust
that the feed publisher may have already done all this work and has
provided a reasonably accurate count in the form of the thr:count
attribute.  It's your choice.

- James

---

From: "Byrne Reese" <[email-masked]>
Date: Wed, 17 May 2006 15:46:09 -0400

Speaking up:

http://www.majordojo.com/atom/standardizing_the_atom_thread_extension.ph
p

No surprise I guess, but I am a huge +1. Lock this spec down and ship
it.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of James M Snell
Sent: Monday, May 15, 2006 3:15 PM
To: atom-syntax
Subject: Feed Thread in Last Call

Hey all,

- James

[1]http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-1
0.txt
[2]https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dT
ag=13577&rfc_flag=0

---

From: John Panzer <[email-masked]>
Date: Wed, 17 May 2006 11:51:34 -0700

>cannot be found otherwise already.
The use case we've identified here is to be able to quickly display the 
comment count attribute on a web page where you have 10 entries.  We 
really don't want to have to make 10 extra remote calls to retrieve 10 
integers when they are so easily included in the top level entry feed; 
in fact, should a standard require this, we'd have to shrug and embed 
the data inside proprietary extensions for performance reasons.

-- 
John Panzer
System Architect, AOL
http://abstractioneer.org

---

From: "James Holderness" <[email-masked]>
Date: Wed, 17 May 2006 18:41:59 -0000

> because I will find those information anyway with the following process:

That's certainly one way of doing things, but not the only way. I'm fairly 
sure there are existing clients that rely on the thread count (using 
slash:comments) to determine whether a replies feed has changed. This makes 
sense when there is a separate feed for each reply - instead of connecting 
to dozens of feeds looking for updates (and hoping they support 304), you 
just download the main feed looking for a change in the thread count.

If you don't like these attributes, that's fine - nobody is forcing you to 
use them. But don't assume that everyone wants to do things the same way as 
you. Don't try and prevent people from doing something different to you just 
because you personally don't like their choice.

Regards
James

---

From: Antone Roundy <[email-masked]>
Date: Wed, 17 May 2006 14:46:41 -0600

> has only changed for the number of comments of an entry.

I do think the document could use a note pointing out that using  
thr:when and thr:count may increase bandwidth usage by reducing the  
number of instances where you can send '304 Not Modified' responses.   
Publishers should weigh the value of those attributes against the  
cost of providing them when deciding whether to include them in their  
feeds.

---

From: "Sylvain Hellegouarch" <[email-masked]>
Date: Wed, 17 May 2006 22:39:47 +0100 (BST)

> because you personally don't like their choice.

The problem I've raised is not about my taste in the end but about making
sure we have taken every aspects into consideration. As you said, maybe
there are other ways of doing than the basic algorithm I suggested but
they do not play on the same level. Anyway, sorry if I came harsh on this
question. I didn't mean it but saying that I don't have to use it if I
don't like it is not really relevant. We re not discussing what each of us
would do but what we want the community to be able to do.

James > Would you consider adding informative documentation on this matter
in the spec or is that out of its boundaries?

- Sylvain

---

From: "Sylvain Hellegouarch" <[email-masked]>
Date: Wed, 17 May 2006 22:42:52 +0100 (BST)

> attribute.  It's your choice.

Fair enough. It sounds reasonable but I'm still not fully convinced. I'm
happy we discussed it anyway.

Thanks,
- Sylvain

---

From: James M Snell <[email-masked]>
Date: Wed, 17 May 2006 15:00:09 -0700

Sylvain Hellegouarch wrote:
> James > Would you consider adding informative documentation on this
> matter in the spec or is that out of its boundaries?

What I intend to do is provide a fairly short section discussing the use
of the thr attributes, a few comments regarding the precision and
authority of their values, and the potential impact that changes to
metadata of any kind in a Feed may have on the cacheability of the feed
document.

The latter is, of course, not specific to FTE, but apparently is enough
of a problem to at least warrant a mention.

- James

---

From: "Byrne Reese" <[email-masked]>
Date: Wed, 17 May 2006 19:45:23 -0400

> However, if I'm an aggregator I don't need the thr:count and thr:when
because I will find
> those information anyway with the following process:
>
> 1. I fetch the comment feed and put it my cache 2. I want to know if a
new comment has
>    been posted, I won't fetch the feed containing the entry but the
feed containing the
>    comment
>  b. A comment added => I fetch the feed again and know both the number
of comments and 
>     the date of the latest one

When Friendster approached Six Apart and asked for a way to keep abreast
as to the comment activity within the Friendster Blogging network
(powered by TypePad), I turned immediately to FTE.

In this implementation, there was actually no desire for Friendster to
gain access to the comments themselves - all they wanted was to know:
has there been a new comment posted to any of this users blog entries?

And in actually, TypePad didn't want to add another page to be rebuilt.
We wanted to keep things as simple as possible, in order to satisfy the
customer's requirements within incurring any more development overhead
than absolutely necessary.

FTE was a perfect fit because it allowed Friendster to monitor comment
activity quite reliably. The count attribute wasn't enough for them
because the count attribute by itself doesn't reflect accurately if a
new comment was posted (e.g. comment count is 0, new comment received,
comment count is 1, comment deleted, comment count is 0, comment
received, etc). Depending upon the poll interval of the client, it may
miss the fact that a comment was posted.

However, the count attribute and then when attribute gave Friendster
just what they needed: enough information to know that a) a new comment
was received, and b) sufficiently (not necessary 100% accurate, but they
didn't care) accurate comment count. They used this information to send
emails to the blog owner saying, since we last emailed you, there has
been this activity on your blog.

The Friendster link relation looks like this:

<link rel="replies" type="text/html"
href="http://..../foo.html#comments"
      thr:when="<date>" thr:count="<int>" />

Notice, in this case we are pointing to the HTML page where comments can
be found - and not to another Atom feed because we don't produce a
comments feed. We simply produce some meta data about comment activity.

Furthermore, Six Apart likes this spec as-is because it helps to reduce
the number of documents that need to be parsed in order to determine
simple details about an entry. The burden of having to fetch an Atom
document for each entry and then counting the number of entries within
that feed to derive a count, is totally absurd. If you CAN make it
easier for a developer, why won't you?

Not to mention that in Friendster's case, this process would not have
worked for them because we didn't produce a feed for them to extract
this information from, because their requirements forbade it. 

I have gone on long enough. I am hoping this gave some good background
around a real implementation and use case currently in use today.

Caveat: Six Apart didn't implement this extension with ANY assumption
that it would remain as-is. James warned me that it could change - and
in fact it did. We implemented it knowing full well it wasn't final. But
despite the risk of it not being final - it was still the best solution
on the market.

Byrne Reese
Manager, Platform Technology
Six Apart, Ltd.

---

From: "Byrne Reese" <[email-masked]>
Date: Wed, 17 May 2006 19:55:54 -0400

> Alternatively, you could decide to
> trust that the feed publisher may have already done all this work and
> has provided a reasonably accurate count in the form of the thr:count

This to me is what its all about. I hear a lot of people saying that you
can't be sure that the comment count is accurate. That the ONLY way to
be sure is to get the whole feed with all the comments.

To those people I would say you have "trust issues."

I am being snide, I admit, but truthfully, why would Six Apart (or any
other implementer) not want to keep the two values in sync when it is so
clear that we SHOULD.

Certainly my implementations do. And if they were ever out of sync (i.e.
the count attribute saying 5, and the feed containing 6) then that is a
bug and I frick'n need to fix that.

Byrne

---

From: "Sylvain Hellegouarch" <[email-masked]>
Date: Thu, 18 May 2006 09:27:37 +0100 (BST)

> of a problem to at least warrant a mention.

Thank you. This is fully appreciated.

- Sylvain

---

From: "Sylvain Hellegouarch" <[email-masked]>
Date: Thu, 18 May 2006 09:26:18 +0100 (BST)

> easier for a developer, why won't you?

Well you simply move the burden to a different level where it is not your
problem anymore, ie on the HTTP level and far from the application level.
It is fine but the load will be paid by someone at any given time.

> around a real implementation and use case currently in use today.

You did and I thank you for sharing this information.

That being said, I raised two points in me original mail:

1. The fact I thought the thr attributes were useless. You made a good
case and I will not fight against their use on the application level
anymore. We are therefore fine on *that* level.

2. The burden added to the HTTP layer. I'll try to make myself clear.

In your implementation above you have to update the Atom feed to modify
the thr attributes. The problem is that you have then to update the last
modified date of the resource (as in the REST definition of resource)
itself (whether you generate ir on the fly or save it on disk).

For aggregators which are aware of the FTE, it won't be so much of a
problem as you showed me because they will know how to deal with that on
the application level and make the best of it.

However, there will be clients which won't care about the semantic of the
resource, their point is simply to fetch a resource and cache it as long
as it is not modified.

By acting as you do, we may end up in a huge amount of feeds being sent on
the wire to clients which believe the feed has actually changed in its
content when it has changed only in one meta-data value (that they will
not handle anyway).

This is my grief. Your use case is great at the application level but
could really mess bandwith usage as well.

That's why I also say you have moved the burden down to one level so that
it doesn't make your life more complicated and so that others pay the
price of it.

I'd be interested to hearing from Friendster about their feed bandwith
usage since you have setup the FTE.

However I'm not blind enough either to realise my algorithm would not be
much better in some circumstances.

I guess my problem is that the semantic conveyed by those attributes
should belong to a push protocol and not to a pulled one like HTTP.

I aslo understand that Atom and its extensions are not protocol aware.
They should not have to care about HTTP. It does not mean though that we
cannot think about their implications in those areas.

Thanks for your feedback.
- Sylvain

---

From: David Powell <[email-masked]>
Date: Thu, 18 May 2006 14:15:43 +0100

> the attributes due to various limitations of a few existing Atom 1.0

That doesn't accurately state my problem with FTE. My concern is more
general than the compatibility with a specific Atom implementations.
The fact that the MS feed platform exhibits the issue is just a
confirmation that the issue is more than a theoretical concern.

An implementor that wants to /consume/ Atom (such as a feed API, or
store), ought to be able to create an accurate implementation just by
reading RFC4287. That document describes what properties entries,
feeds, links, and extension elements have, and how they are
represented in an Atom document. Using this it is possible to create a
database schema or OO API that can represent feed data.

My problem with FTE is that rather than using Atom's extension-point:
the "Extension Element" (which an implementor of RFC4287 is likely to
be capable of preserving), it uses the fact that Atom doesn't prohibit
extra attributes to be included anywhere in the document. Is an API,
feed store, or Atom Protocol implementation expected to preserve every
attribute on every element, in addition to the core elements, and
extension points? This might be practical on a few green-field Atom
implementations, but it wouldn't be practical on systems than need to
be retrofitted to support Atom.

What I see as a problem is that reasonable implementations will not
preserve Atom documents bit-for-bit, so they will need to explicitly
support this draft if they don't want to corrupt data by dropping the
thr:count attributes. By the letter of RFC4287 there is no problem
with the draft, but practically there is something like a layering
concern if an extension requires existing conformant implementations
to be changed.

Atom implementations with generic support for links and extensions,
will find that this draft moves the goalposts of what a reasonable
implementation is expected to handle, and I firmly believe that it
should be possible for implementations to provide generic support for
extensions in order to assist their adoption.

Part of the problem might be caused by flaws in Atom's extensibility
model, but that is all the more reason for extensions to be
conservative in its use.

> implemented support for the extension has had any problems with them.

Does that include any stateful feed APIs, or APP servers that aren't
based on native XML back-ends?

I notice that you said "implemented support" - that is fine for
user-agents etc, but I don't believe that Atom infrastructure should
be required to "implement support" for each new bit of content that
publishers put into their feeds.

-- 
Dave

---

From: "Hugh Winkler" <[email-masked]>
Date: Thu, 18 May 2006 08:24:03 -0500

> content when it has changed only in one meta-data value (that they will

Servers don't *have* to change the feed's Last-Modified and ETag values when
a comment count changes. They are free to respond 304 to a conditional GET,
even if the count has changed.

Hugh

---

From: "Sylvain Hellegouarch" <[email-masked]>
Date: Thu, 18 May 2006 14:58:57 +0100 (BST)

> even if the count has changed.

Well this is debatable because you effectively change the resource itself
and ought to update its meta-data as well (ie Last-Modified and Etag
values).

Besides, by not doing so can be even worse because an aggregator would
requests the feed, the server would respond with a 304 and the aggregator
would not even know the count ahs changed in the end. It feels even worse.

- Sylvain

---

From: "Sylvain Hellegouarch" <[email-masked]>
Date: Thu, 18 May 2006 15:12:26 +0100 (BST)

> would not even know the count ahs changed in the end. It feels even worse.

Actually the aggregator could NOT send the If-Modified-Since header of
course in that specific case and be safe. But this seems like a bit of an
abuse of HTTP to me.

- Sylvain

---

From: Brendan Taylor <[email-masked]>
Date: Thu, 18 May 2006 08:10:38 -0600

> content when it has changed only in one meta-data value (that they will

It's a valid concern, but as James has been saying the "problem" is with
the syndication model. This isn't something that Atom (or any extension) 
can solve.

Do you have any suggestions about how this metadata could be included
without changing the content of the feed? AFAICT the only solution is to
not use the attributes (which aren't required, of course).

---

From: "Sylvain Hellegouarch" <[email-masked]>
Date: Thu, 18 May 2006 15:28:05 +0100 (BST)

> the syndication model. This isn't something that Atom (or any extension)

I agree with you and James. This is much larger issue and this spec is not
the right place to try solving it.

> not use the attributes (which aren't required, of course).

I'll make a fool of myself after being so virulent but apart from a fairly
big change in the Internet architecture. There is little that could be
done to solve the problem of polling Vs pushing.

That being said, I would not be surprised that ISPs push really hard for
such a discussion to happen as they will soon be overloaded by the huge
amount of data passing on the wires they pay for (thinks much larger than
just feeds like HDTV ;).

Anyway, no I don't have a better solution. I am nevertheless happy that
the point will be notified by James in its draft.

- Sylvain

---

From: "Sylvain Hellegouarch" <[email-masked]>
Date: Thu, 18 May 2006 15:35:43 +0100 (BST)

And I am sorry for the numerous mistakes I make in my written English. *sigh*

---

From: James M Snell <[email-masked]>
Date: Thu, 18 May 2006 08:27:42 -0700

David,

> confirmation that the issue is more than a theoretical concern.

My apologies for the misrepresentation. It was unintentional.

> database schema or OO API that can represent feed data.

When I look at RFC4287 I see the following statements:

  1.3 : "Some sections of this specification are illustrated with
         fragments of a non-normative RELAX NG Compact schema
         [RELAX-NG].  However, the text of this specification provides
         the definition of conformance."
4.2.7 : "The "atom:link" element defines a reference from an entry or
         feed to a Web resource.  This specification assigns no meaning
         to the content (if any) of this element."
  6.1 : "Markup from other vocabularies ("foreign markup") can be used
         in an Atom Document."
  6.3:  "Atom Processors that encounter foreign markup in a location
         that is legal according to this specification MUST NOT stop
         processing or signal an error."
  6.4:  "Atom allows foreign markup anywhere in an Atom document, except

         where it is explicitly forbidden."

Further, the RELAX NG definition for atom:link is,

   atomLink =
      element atom:link {
         atomCommonAttributes,
         attribute href { atomUri },
         attribute rel { atomNCName | atomUri }?,
         attribute type { atomMediaType }?,
         attribute hreflang { atomLanguageTag }?,
         attribute title { text }?,
         attribute length { text }?,
         undefinedContent
      }

   atomCommonAttributes =
      attribute xml:base { atomUri }?,
      attribute xml:lang { atomLanguageTag }?,
      undefinedAttribute*

   undefinedAttribute =
     attribute * - (xml:base | xml:lang | local:*) { text }

   undefinedContent = (text|anyForeignElement)*

My interpretation of the text and the RELAX NG definition is that while
the specification does not assign any meaning to extensions of the link
element, it is nonetheless explicitly allowed.

It may have been a mistake, but the discussion of section 6.4 is
explicitly scoped *only* to child elements of atom:entry, atom:feed,
atom:source and Person constructs. Note that this section does NOT state
that ONLY those elements may be extended; rather, the section defines
the characteristics of two types of extensions that could occur on those
subsets of elements.  The characteristics of extensions on other
elements in the Atom vocabulary are left undefined.

The definitions of the atomCommonAttributes (which allows any number of
"undefinedAttributes" and the definition of undefinedContent is very
clear on the point that extensions ARE allowed on Link.  Such extensions
may not be semantically meaningful to RFC4287, but they are nonetheless
legal and a valid component of the Atom data model.

> concern if an extension requires existing conformant implementations

Atom does not define any notion of "conformance".  That is, there are no
requirements anywhere that define what aspects of the Atom data model an
implementation MUST/SHOULD/MAY support. It is, therefore, reasonable to
expect that different implementations will offer varying levels of
support for a variety of the core features offered by the protocol.  For
instance, Atom's data model allows for multiple enclosure links.  In my
Atom implementation, this is easily handled and exposed by the API; in
Microsoft's implementation, however, only a single enclosure is exposed.
 Some implementations do not expose any link other than the first
"alternate" link that they happen to find in the entry.

I'm sure there are countless such examples.  Some implementations don't
use/preserve the scheme attribute on the category element; some
implementations don't fully support the atom content model (e.g. base64
encoded content); some implementations don't support XML digital
signatures; etc.

Because there is no definition of conformance, even for the core Atom
format, it is perfectly reasonable to expect that existing
implementations may have to change a bit in order to support the
introduction of new extensions, depending on the level of support they
have for the full atom data model as defined by RFC4287.

> extensions in order to assist their adoption.

RFC4287 sets the goal posts. Extension attributes and elements ARE
allowed on Link.  Whether or not an implementation chooses to support
such extensions is an implementation choice.

> based on native XML back-ends?

I am not certain what you mean by "stateful feed APIs", but the answer
is yes to the question about non-native XML back-ends.

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 18 May 2006 17:54:48 +0200

* James M Snell <[email-masked]> [2006-05-18 17:40]:
> My interpretation of the text and the RELAX NG definition is
> that while the specification does not assign any meaning to
> extensions of the link element, it is nonetheless explicitly
> allowed.

Noone ever debated that.

> It may have been a mistake, but the discussion of section 6.4
> is explicitly scoped *only* to child elements of atom:entry,
> atom:feed, atom:source and Person constructs.

That was a mistake, yes. Unfortunately, hindsight is 20/20.

> Note that this section does NOT state that ONLY those elements
> may be extended; rather, the section defines the
> characteristics of two types of extensions that could occur on
> those subsets of elements. The characteristics of extensions on
> other elements in the Atom vocabulary are left undefined.

Yes. That means extending other elements is a free-for-all just
as it is in RSS 2.0, and we know the problems that this poses in
practice. Extending Atom in ways other than those defined in Sec
6.4. has the same problems as extending RSS 2.0 with namespaced
elements.

Regards,

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 18 May 2006 18:35:12 +0200

* Robert Sayre <[email-masked]> [2006-05-18 18:05]:
> There's no technical reason for the placement of the
> attributes,

Do you have better ideas on how to provide this information on a
per-link basis? It would help if you actually tried to suggest an
approach instead of bashing what’s there.

Regards,

---

From: Antone Roundy <[email-masked]>
Date: Thu, 18 May 2006 11:48:58 -0600

> not use the attributes (which aren't required, of course).

If it's in the feed document and it gets updated other than when the  
entry itself is updated (...and it wouldn't be of much use if it were  
only updated when the entry was updated), it's going to result in  
data getting re-fetched when nothing but the comment count and  
timestamp change.  I don't see any way around that.  So if you really  
want a way to publish comment counts and timestamps without causing  
lots of unchanged data from getting refetched, you're going to have  
to separate that data out of the feed. Here's pseudo-XML for a  
possible approach:

<feed ...>
	...
	<link rel="comment-tracking" href="..." />
	...
	<entry>
		<id>foo</id>
		...
	</entry>
	<entry>
		<id>bar</td>
		...
	</entry>
	...
</feed>

and in another document:

<ct:comment-tracking xmlns:ct="..." xmlns:atom="..." ...>
	<atom:link rel="related" href="URL of the feed" ... />
	<ct:entry ref="foo">
		<atom:link rel="comments" href="..." type="..." hreflang="..."  
ct:count="5" ct:when="..." />
		<atom:link rel="comments" href="..." type="..." hreflang="..."  
ct:count="3" ct:when="..." />
	</ct:entry>
	<ct:entry ref="bar">
		<atom:link rel="comments" href="..." type="..." hreflang="..."  
ct:count="0" ct:when="..." />
		<atom:link rel="comments" href="..." type="..." hreflang="..."  
ct:count="1" ct:when="..." />
	</ct:entry>
	...
</ct:comment-tracking>

Of course the comment tracking document wouldn't only be  
authoritative for feeds that pointed to it with a comment-tracking link.

This would require an extra subscription to track the comments, as  
well as understanding an additional format (as opposed to just an  
additional extension--either approach requires SOME additional work),  
but it would prevent unnecessary downloads by clients that aren't  
aware of it, and would reduce the bandwidth used by those that are.

This approach could be generalized to enable offloading of other  
metadata that's more volatile than the entries themselves.

Antone

---

From: "Robert Sayre" <[email-masked]>
Date: Thu, 18 May 2006 17:56:39 +0200

Look at that giant email. Seems to me that it's a debate taking place
for no discernable reason. There's no technical reason for the
placement of the attributes, and management has made it clear that any
objections are "irrelevant."

Hope that helps!

-- 

Robert Sayre

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 18 May 2006 20:31:39 +0200

* Antone Roundy <[email-masked]> [2006-05-18 20:05]:
> 		<atom:link rel="comments" href="..." type="..." 
> 		hreflang="..."  ct:count="5" ct:when="..." />
> 		<atom:link rel="comments" href="..." type="..." 
> 		hreflang="..."  ct:count="3" ct:when="..." />
> 	</ct:entry>
> 	<ct:entry ref="bar">
> 		<atom:link rel="comments" href="..." type="..." 
> 		hreflang="..."  ct:count="0" ct:when="..." />
> 		<atom:link rel="comments" href="..." type="..." 
> 		hreflang="..."  ct:count="1" ct:when="..." />
> 	</ct:entry>
> 	...
> </ct:comment-tracking>
> 
> This would require an extra subscription to track the comments,
> as well as understanding an additional format (as opposed to
> just an additional extension--either approach requires SOME
> additional work), but it would prevent unnecessary downloads by
> clients that aren't aware of it, and would reduce the bandwidth
> used by those that are.
> 
> This approach could be generalized to enable offloading of
> other metadata that's more volatile than the entries
> themselves.

Actually, you don’t really need another format. There’s no reason
why you couldn’t use atom:feed in place of your hypothetical
ct:comment-tracking. :-) Your ct:entry elements could almost be
atom:entry ones instead, too, except that assigning them titles
and IDs feels like overkill.

The real cost is not the cost of an extra format, but that
implementations then need to understand the FTE in order to know
to poll an extra document to retrieve the out-of-band metadata.

Regards,

---

From: Antone Roundy <[email-masked]>
Date: Thu, 18 May 2006 13:25:21 -0600

> and IDs feels like overkill.
The point of the whole exercise is to create a lightweight document  
for volatile metadata. If it's an atom:feed, you have to include a  
lot of stuff that's not needed here--atom:title, atom:updated,  
atom:author, and atom:summary or atom:content.  Also, you'd need to  
have an atom:id for each entry in addition to the @ref pointing to  
the entry that it talks about.

> to poll an extra document to retrieve the out-of-band metadata.
Sure, but if they don't understand FTE, they wouldn't know what to do  
with the extra metadata anyway even if it were in the main feed.   
They MIGHT be able to do some generic processing of the comments  
link, but the reliability of any generic processing algorithm for  
unknown link types is questionable since we left atom:link open to  
all sorts of uses.  And you COULD keep the comments links in the main  
feed but just leave off @count and @when for the benefit of apps that  
don't process the sibling document.

> metadata that's more volatile than the entries themselves.
I don't know yet what other metadata might be handled this way, but  
here's slightly revised pseudo-XML that makes it more general and  
adds a few useful things:

<feed ...>
	<id>foobar</id>
	...
	<link rel="volatile" href="..." />
	...
	<entry>
		<id>foo</id>
		...
	</entry>
	<entry>
		<id>bar</td>
		...
	</entry>
	...
</feed>

<v:volatile ref="foobar" xmlns:v="..." xmlns="http://www.w3.org/2005/ 
Atom" xmlns:thr="..."><!-- @ref could be omitted if using with RSS -->
	<link rel="related" href="URL of the feed" ... /><!-- don't really  
need something different from "related", right? -->
	<updated>...</updated>
	<v:entry ref="foo"><!-- @ref could be a guid if using with an RSS  
2.0 feed, though we all know that RSS 2.0 guids are misused in ways  
that might make the connection unreliable -->
		<updated>...</updated>
		<link rel="comments" href="..." type="..." hreflang="..."  
thr:count="5" thr:when="..." />
		<link rel="comments" href="..." type="..." hreflang="..."  
thr:count="3" thr:when="..." />
	</v:entry>
	<v:entry ref="bar">
		<updated>...</updated>
		<link rel="comments" href="..." type="..." hreflang="..."  
thr:count="0" thr:when="..." />
		<link rel="comments" href="..." type="..." hreflang="..."  
thr:count="1" thr:when="..." />
	</v:entry>
	...
</v:volatile>

---

From: "M. David Peterson" <[email-masked]>
Date: Thu, 18 May 2006 14:02:44 -0600

<a:f id="idoffeed" a:ds="1">
<a:e id="idofentry" a:r="2">
<a:c id="idofcomment" a:r="1">
<a:c id="idofcomment" a:r="2"/>
</a:c>
</a:e>
<a:e id="idofentry: a:r="3"/>
</a:f>

The requestor sends a request for all entries and comments on those entiries
since a certain date.  If the date request is considered reasonable, a
compact atom syntax that contains,

a) a determination as to whether they support providing diffs a:ds="0"
false, a:ds="1", true

b) the relavent pieces necessary to determine if,

b:1) you have a local instance of that id.
b:1:1) If yes, compare the revision (a:r) value.
b:1:1:1) If the same, ignore,
b:1:1:2) if different, the difference is determined, and stored until the
compact syntax above has finished being processed.
b:1:2) If there is no local instance of that id, store the this until the
process has finished.

recurse until complete.

recurse the result:
a: If you can process the diff, and they support returning just the diff,
set a request header determined to specify this to the server.
b: set a header to specify to the server if you want the exact specified
revision, or additional revisions if they have changed since the original
query.
c: return a request for each updated or new resource, with the difference
between the local revision number and the revision number on the server if
appropriate.

each request is initially atomic, with the ability to be grouped if the
server determines that it would be more efficient at present time to handle
one request at a time, or grouped together using a conanical compression of
the requested items.  This would be returned in the response header such as
to maintain a consistent ability to adapt at any moment to current oad on
the server.

nothing is approximate, each side of the transaction has the ability to
adapt to change, and to decide if it wants to handle potential differences
that take place during the span between requests now, or at a later date.
With each transaction, enough information is provided to quickly calculate
and determine, or specify a default if the current load is past a certain
threshold, while still maintaining the knowledge that updates exists, and
when the load allows, make a new request based on the difference in stored
values that pertain to each id  it has knowledge to have differences.

If during this span, the server in which receives the request realizes that
since the last request, a resource has been removed/deleted, a header can be
set to specify that future calculations should be based on the new
difference instead of the old.

----
In the above scenario the amount of data exchange is at a bare minimum, the
processing required to calculate the differences is at a bare mininum, it
maintains a level of data integrity that is granular enough to adapt to each
change in the system, without requirement of extensive processing to
determine this difference, while maintaining an agile/adaptible foundation
that can adjust as needed without loss of data integrity on either side of
the transaction.

Given the amount of data sent with initial request is at a bare minimum,
this can be set in memory as the default response based on the time
difference to determine the address of where to begin streaming the request,
using the default a:f id="feedid" to open/close the response stream at the
appropriate start and stop point of the returned stream.

Please disregard the above if I have left out obvious areas in which makes
this irrelevant.  Not trying to take a "this is the absolute right way to do
this" and instead inject the smallest, simplest path that seems to logically
provide the necessary pieces to make the transaction processing of
differences as simple and efficient as possible, while doing so in a way
thats just outside the box, but close enough as to not require any changes
to any actual draft specifications, and instead a way to illiminate some of
the concerns presented that suggested potentials areas of inefficient or
innacurate behaviors that hold potential for problems down the road.

Peace :)

On 5/18/06, A. Pagaltzis <[email-masked]> wrote:
> Actually, you don't really need another format. There's no reason
> why you couldn't use atom:feed in place of your hypothetical

-- 
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 18 May 2006 21:51:24 +0200

* Antone Roundy <[email-masked]> [2006-05-18 21:40]:
> The point of the whole exercise is to create a lightweight
> document for volatile metadata. If it's an atom:feed, you have
> to include a lot of stuff that's not needed here--atom:title,
> atom:updated, atom:author, and atom:summary or atom:content.
> Also, you'd need to have an atom:id for each entry in addition
> to the @ref pointing to the entry that it talks about.

I did say that atom:entry is overkill. You could still use a feed
document, though. If you have no atom:entry in it you can elide
the feed-level atom:author, and the other required elements for a
feed (atom:id and atom:updated) seem like a good idea to have in
this sort of document. Only atom:title is unnecessary, but that
does not feel like a big burden.

> Sure, but if they don't understand FTE, they wouldn't know what
> to do with the extra metadata anyway even if it were in the
> main feed.

That is only half correct. The point of Sec 6.4 is to allow
intermediaries at the infrastructure level (which includes things
like the RSS Platform) to store and pass on extension metadata
generically, without having to understand what a particular
extension means. If you put this metadata out of band, then the
application layer has to take on infrastructure layer
responsibilities.

Note that I’m not arguing against the approach. It seems like an
interesting idea. I’m just pointing out that it does have costs.

Regards,

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 18 May 2006 17:40:43 -0700

> objections are "irrelevant."

I realize that the placement of the attributes is one choice among  
many.  Sometimes you just have to make a choice and there's no reason  
beyond "it needs to go somewhere".  I've been trying to understand if  
there's a technical problem with the draft's chosen placement of the  
attributes and the best case I've seen is that "that location is  
technically disallowed by RFC4287", an assertion which is disputed  
(alas, natural language meanings are often disputed).

Am I missing something in the case against the choice of location for  
the metadata?

Thanks,
Lisa

---

From: "Robert Sayre" <[email-masked]>
Date: Fri, 19 May 2006 11:06:06 +0200

> Am I missing something in the case against the choice of location for

Yes. That location is going to cause interoperability problems in my
implementation, because the draft leaves too much undefined, and in
implementations who won't parse them. I think I've made that extremely
clear. The previous draft addressed my concerns. My current plan is to
implement the threading element, but I'll recommend against accepting
bug reports on the other aspects of the document, since I think it's
an underspecified mess. Kind of silly considering the clear lessons
from earlier efforts, but the threading element is good enough.

-- 

Robert Sayre

---

From: James M Snell <[email-masked]>
Date: Fri, 19 May 2006 12:13:57 -0700

> implementation, because the draft leaves too much undefined, and in

Other than the issue with the Microsoft implementation, which has
already been thoroughly discussed, what other interop problems are you
anticipating?  A clear, non-editorialized, listing of the potential
issues and the rationale for each would be most helpful.

- James

---

From: "Robert Sayre" <[email-masked]>
Date: Fri, 19 May 2006 22:38:52 +0200

> issues and the rationale for each would be most helpful.

You've received several of those from me. I suggest you read your old
mail, paying close attention to messages that you replied to in under
15 minutes.

I have zero confidence that any technical change or compromise is
possible from you, and I find interacting with you to be a giant time
sink. My new policy will be to explain my problem *once*, and then I
will verify that my concerns (if any) have been addressed at some
later date when there is a revised document available. If my concerns
aren't addressed, I will make a concerted effort to avoid writing or
being responsible for maintaining any relevant functionality.

-- 

Robert Sayre

---

From: David Powell <[email-masked]>
Date: Sat, 20 May 2006 16:49:42 +0100

Friday, May 19, 2006, 1:40:43 AM, Lisa Dusseault wrote:

> I've been trying to understand if there's a technical problem with
> the draft's chosen placement of the attributes and the best case
> I've seen is that "that location is technically disallowed by
> RFC4287" , an assertion which is disputed (alas, natural language
> meanings are often disputed).

Hmm, that wasn't my argument either... I fully agree that the
attributes are technically allowed by both the text and RelaxNG of
RFC4287. I don't think anyone is disputing that.

Sorry for repeating myself again, but I'll recap my argument in full
because it seems like it hasn't been understood.  A bit of background:

Modelling
=========

Software that deals with XML such as an XHTML document, doesn't have
much choice but to model the document using generic XML concepts and
tools - Infosets, DOM, SAX, strings containing XML tags, etc.

For Atom though, it is useful to model feeds and entries in terms of
some other data model: OO, RDBMS, WebDAV (I've been doing it as RDF,
but that is a dirty word around these parts). Some of the reasons for
this are:

  Most Atom implementations are concerned with the combined state of a
  feed over time, not the state of an individual feed document, so
  pure XML access is inadequate.

  More robust, and efficient implementations, particularly in the case
  of RDBMS.

  Implementations may be built upon existing systems, such as existing
  content management systems, where a mapping between Atom the XML
  syntax, and the entities in an existing system would need to be
  established.

  Even the best XML APIs are horrible to use when compared to domain
  specific APIs.

Extensions
==========

Atom standardised a minimal set of elements, with the expectation that
any other elements would be created as extensions. It is therefore
important that Atom infrastructure shouldn't get in the way of the
deployment of extensions. Atom uses mustIgnore semantics for
extensions, which allows implementations to copy-through extensions
even if they don't understand their purpose.

Section 6 of RFC4287 is flawed. It is an ugly mix of my (overly)
strict PaceExtensionConstruct proposal[1], and an (overly) liberal
philosophy that the existence of foreign markup anywhere won't break
implementations, so shouldn't be disallowed.

[1] http://www.intertwingly.net/wiki/pie/PaceExtensionConstruct?action=recall&date=1105566248

I complained about it here[2], admittedly a long time after IETF last
call, but as we were still making Atom 101 changes about then (eg:
let's allow multiple authors), maybe that wasn't so unreasonable. It
doesn't make any sense to define two very precise classes of extension
element, and then say that any extra markup can go anywhere, without
giving any justification or explanation to why we did this, or any
guidelines to why extension authors should pick each of these options.

[2] http://www.imc.org/atom-syntax/mail-archive/msg15915.html

Unfortunately Simple Extension elements are too unconstrained to fulfil
their original objective, so the difference between them and
Structured Extensions is academic. The intent was that Simple
Extensions were a class of extension whose values were context-free
strings that would be easy to implement, and easy to provide UIs for,
and extension proposers might be encouraged to choose this class of
extension where it was appropriate for improved interoperability. I
don't think that this worked out.

The difference between extension elements, and foreign attributes is
significant however.

atompub's charter states:

> Atom consists of:
>     * A conceptual model of a resource
>     * A concrete syntax for this model

Extension elements are defined to have both a model and a syntax, but
Atom's allowance for foreign attributes to appear anywhere is a case
of syntax that has no corresponding model. Atom doesn't really explain
what foreign attributes are intended for. It seems like they could be
an extension point, but given that many implementations will have an
application model that isn't based on the XML Infoset (as described
above), it seems very unwise to create an extension proposal which
depends on the precise syntax of an element being preserved.

The intent of Simple Extensions was to provide a class of extension
that was more interoperable; foreign attributes appear to provide a
class of extension (if that is what it is) that will be much less
interoperable.

Some guidance in how to design extensions is definitely missing from
the RFC, perhaps an Informational RFC explaining the issues would be
appropriate.

Relevance of intermediaries
===========================

Most of these issues only apply to Atom intermediaries: agents which
much accept Atom documents, and represent the documents internally
without losing information.  It doesn't matter if a desktop aggregator
drops extensions if it has no UI for displaying them anyway.  But I
think that the class of Atom intermediaries will become larger, and
more important:

  All implementations of Atom Publishing Protocol are Atom
  intermediaries.

  Value-added feed services, such as FeedBurner.

  Microsoft's Feed Platform

  As soon as a desktop aggregator allows plugins for display and
  processing of extensions, it becomes an intermediary.

Behaviour of intermediaries
===========================

Atom makes no attempt to standardise the behaviour of intermediaries.
A feed store can strip extensions, contributors, or everything but
mandatory elements; it can even mutate these core elements - it is
just a "quality of implementation" issue. For blogging applications
this is acceptable, for web-service-like implementations, perhaps
some conformance levels for the preservation of markup might be useful
in future.

The lack of standardisation is not necessarily a bad thing,
implementations are free to implement what is appropriate to their
requirements - if implementations were required to preserve everything
perfectly it would massively raise the cost of integrating Atom with
existing systems.

Publishers (and especially the proposers of extensions), need to be
mindful of the varying support of implementations:

As an extension proposal makes greater requirements on software, the
chances of information loss, and interop problems increases.
Especially considering as scenario such as using an off-line blog
editor, talking to an Atom Protocol Server, providing a feed via
FeedBurner, to an application running on top of Microsoft's Feed
Engine. It becomes important to be conservative with the use of so
many unstandardised components.

Anyway the conclusions I take from all of this are:

Foreign attributes are bad, and are inherently less interoperable
than Extension Elements.

Interoperability should take priority of concerns that 'approach X looks
better than Y', and other unjustifiable minor concerns.

It is a bad precedent for the first IETF approved extension to rely on
such a fragile part of RFC4287.

Some sort of BCP for extension proposers would be useful to explain
the issues. Perhaps foreign attributes could be clarified as being a
3rd class of extension and reincorporated into the Atom model, with
the disclaimer that they are less interoperable than Simple &
Structured Extensions?

-- 
Dave

---

From: Tim Bray <[email-masked]>
Date: Tue, 23 May 2006 12:08:18 -0700

On May 17, 2006, at 12:46 PM, Byrne Reese wrote:

> Speaking up:
>
> http://www.majordojo.com/atom/ 
> standardizing_the_atom_thread_extension.ph
> p
>

Me too.  Does something useful, does no harm, if it's broken in some  
way it'll be harmlessly routed around.  I suspect that  
implementations that are stupid about the contents of <atom:link>  
will be fixed pretty soon. -Tim

---

From: Tim Bray <[email-masked]>
Date: Tue, 23 May 2006 12:16:23 -0700

> concern if an extension requires existing conformant implementations

At the end of the day, the marketplace will work within the  
constraints of what 4287 allows; my feeling is that there are going  
to be a ton of extensions that will attach unforeseen metadata at  
arbitrary points with Atom documents, and implementations that fail  
to store these and make them retrievable will quickly be seen as  
broken.  -Tim

> publishers put into their feeds.

On the contrary; I think that implementors who fail to deal with the  
fact that people will be adding their own non-Atom stuff at every  
conceivable place in an Atom feed are being very stupid, because this  
will happen whatever we say. -Tim

---

From: James M Snell <[email-masked]>
Date: Tue, 23 May 2006 12:26:44 -0700

+1. What Tim said.

- James

Tim Bray wrote:
> At the end of the day, the marketplace will work within the constraints
> of what 4287 allows; my feeling is that there are going to be a ton of
> extensions that will attach unforeseen metadata at arbitrary points with
> Atom documents, and implementations that fail to store these and make
> them retrievable will quickly be seen as broken.  -Tim
>

---

From: Ernest Prabhakar <[email-masked]>
Date: Tue, 23 May 2006 12:30:26 -0700

I've had a hard time following this thread, but for what its worth I  
buy Tim's reasoning.

+1

On May 23, 2006, at 12:26 PM, James M Snell wrote:

>> constraints

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Tue, 23 May 2006 22:21:19 +0100

>
> Welcome to the messy world of standards. There might be a need for an 
> updated FTE RFC. On the other hand, if the market gives a big yawn, 
> there is probably no need to update the RFC if no one is using it. On 
> the third hand, it doesn't hurt to have it updated anyway; there are 
> lots of RFCs that have barely any implementations. There is probably a 
> fourth hand consideration as well.
>
> There is no clear delineation point for when an extension should 
> become an RFC. The IETF plays it by ear. For some protocols, lots of 
> extensions as RFCs has been a boon; for others, just a bother. We 
> won't know where the Atom format fits in that range for a few years.
>
Thanks a lot for that honest answer Paul. Appreciated :)

- Sylvain

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 23 May 2006 14:10:10 -0700

At 8:39 PM +0100 5/23/06, Sylvain Hellegouarch wrote:
>Sounds about right. Where do we stop then? If the marketplace 
>decides, is there a need to submit the FTE to the IETF? Will any 
>extensions need to be submitted? Only Atom per see needed to be 
>standardised in such a case.

Welcome to the messy world of standards. There might be a need for an 
updated FTE RFC. On the other hand, if the market gives a big yawn, 
there is probably no need to update the RFC if no one is using it. On 
the third hand, it doesn't hurt to have it updated anyway; there are 
lots of RFCs that have barely any implementations. There is probably 
a fourth hand consideration as well.

--Paul Hoffman, Director

---

From: Tim Bray <[email-masked]>
Date: Tue, 23 May 2006 14:31:37 -0700

On May 20, 2006, at 8:49 AM, David Powell wrote: (at great length)

I'm going to re-organize David's argument a little and deal with one  
of his last points first.

> Foreign attributes are bad, and are inherently less interoperable

I would say that furious debates about elements-vs-attributes have  
been going on since the dawn of XML in 1998, but that would be  
untrue; they've been going on since the dawn of XML's precursor SGML  
in 1986.  They have never led anywhere.  After you've noticed that if  
you need nested element structure you're stuck with elements, and if  
you don't want to have two things with the same names attributes can  
help, there really aren't any deterministic decision procedures.

I note with pleasure that *all* known XML APIs allow you to retrieve  
elements and attributes with about the same degree of difficulty.

So, my conclusion: I disagree with Powell.  Let people put extensions  
wherever they feel like putting them (they will anyhow), remembering  
that human-readability is a virtue.  If models try to micro-manage  
the element/attribute thing, those models are broken, don't use  
them.  If software arbitrarily discards markup because the markup  
doesn't match its idiosyncratic ideas about elements and attributes,  
that software is non-comformant and non-interoperable.

> but that is a dirty word around these parts).

Well yes, but each and every one of those non-XML models fails to  
capture the information content of perfectly-legal XML in one way or  
another.  The Atom data format *could* have been designed in such a  
way as to be conformant with one or more of those models, but it  
wasn't.  Extensions to Atom can be designed in such a way as to fit  
into some particular data model, or not.

So I think it's really questionable to try to normatively reverse  
engineer the WG consensus to try to pretend that Atom documents can  
usefully be processed as anything but XML.

> Section 6 of RFC4287 is flawed. It is an ugly mix

I agree.  In fact, what Simple Extension *really* says is "this  
property can trivially be modeled in RDF" and Structured Extension  
really says is "doesn't directly map to RDF", but I failed to  
convince the WG either to remove this hand-waving or to be clear  
about what we really meant.  Having said that, these notions  
fortunately have exactly zero normative effect on implementors.

> of my (overly)

I have no comment on your proposal, but the philosophy you describe  
does in fact represent the consensus of the WG and the IETF  
community; your opinion that it is overly liberal is interesting but  
not particularly relevant to implementors.

> what foreign attributes are intended for.

Extension elements also, as noted above, have *no normative effect*.   
It is arguable that the design of Atom departed from the charter in  
that the model was never explicitly specified.  To me, this seems  
like sound design; the success of the Web has been based on careful  
specification of the content and sequence of the interchanged  
messages without any attempt to standardize on a model.  This is A  
Good Thing, and demonstrably works.

And Atom also doesn't really explain what foreign elements are  
intended for either.

> It seems like they could be
> above),

There's a word for implementations (especially intermediaries, as you  
notice) that aren't based on the Infoset: broken.  Because RFC4287 is  
explicitly defined only in terms of the infoset.  Go ahead and try to  
impose any models that are appropriate for your application needs; I  
do this all the time.  But don't change the Infoset.

> it seems very unwise to create an extension proposal which

The "precise syntax" claim is utterly bogus.  RFC4287 properly  
standardizes at the Infoset level, thus it makes zero difference  
whether I say <title>Café</title> or <title>Caf&#xe9;</title>.  I  
personally think that an extension proposal should

(a) be useful
(b) be readable
(c) not rely on anything that isn't preserved in the XML Infoset

> foreign attributes appear to provide a

This is only true for software which ignores the fact that RFC4287 is  
specified only in terms of the XML Infoset.  If you lose information  
because it doesn't match up with some ex post facto model you've  
dreamed up, you cannot expect to achieve interoperability.

> the RFC, perhaps an Informational RFC explaining the issues would be

Agreed.  But I predict you'll have a devilish hard time building any  
consensus that goes further than my (a), (b), and (c) above.

> perfectly it would massively raise the cost of integrating Atom with

For good interoperability, they should not do violence to the content  
of what they are given, as seen in information-set terms.  Not much  
more (or less) can be asked.

> chances of information loss, and interop problems increases.

Obviously, but the notion that this depends on whether you use an  
attribute or an element seems really, really bizarre to me.  An  
intermediary that drops markup it doesn't recognize won't last long  
in the marketplace, whether those are elements or attributes.

> better than Y', and other unjustifiable minor concerns.

Yes, and interoperability is based on the normative rules in RFC4287,  
right?

> Perhaps foreign attributes could be clarified as being a

I would vociferously resist any such claim. -Tim

---

From: "Robert Sayre" <[email-masked]>
Date: Tue, 23 May 2006 17:47:46 -0400

On 5/23/06, Tim Bray <[email-masked]> wrote:
>
> I would vociferously resist any such claim.

OTOH, there are more than a few products on the market right now that
back up just such a claim. So there's an existence proof, and most of
the APIs I've seen *do* make use simple vs. structured, but you may be
right that the market will change that. In otherwords, there is little
point in continuing this discussion... just like you and I agreed 150+
messages ago...

-- 

Robert Sayre

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Tue, 23 May 2006 20:39:59 +0100

> constraints of what 4287 allows; my feeling is that there are going to 
> be a ton of extensions that will attach unforeseen metadata at 
> arbitrary points with Atom documents, and implementations that fail to 
> store these and make them retrievable will quickly be seen as broken.  
> -Tim
>
>
Sounds about right. Where do we stop then? If the marketplace decides, 
is there a need to submit the FTE to the IETF? Will any extensions need 
to be submitted? Only Atom per see needed to be standardised in such a case.

- Sylvain

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 24 May 2006 11:48:06 +0200

* Tim Bray <[email-masked]> [2006-05-23 23:40]:
> On May 20, 2006, at 8:49 AM, David Powell wrote:
> >Foreign attributes are bad, and are inherently less
> >interoperable than Extension Elements.
> 
> I would say that furious debates about elements-vs-attributes
> have been going on since the dawn of XML in 1998, but that
> would be untrue; they've been going on since the dawn of XML's
> precursor SGML in 1986. They have never led anywhere. After
> you've noticed that if you need nested element structure you're
> stuck with elements, and if you don't want to have two things
> with the same names attributes can help, there really aren't
> any deterministic decision procedures.
> 
> I note with pleasure that *all* known XML APIs allow you to
> retrieve elements and attributes with about the same degree of
> difficulty.

As I read David’s argument, this has nothing to do with elements
vs attributes and everything to do with Extension Elements vs
foreign markup. It doesn’t make a whiff of difference to David’s
argumen whether the Feed Thread Extension standardised on
providing this information as child elements or attributes of
atom:link. The considerations are exactly the same: model vs
syntax.

----

By and large, I agree with him that it would have been beneficial
to specify Atom just a little more closely at a model level. But
I also agree with you that aspiring to much higher rigor beyond
the Infoset level is unnecessary.

My retrospective opinion is that the correct approach would have
been to specify that an Atom Feed Document consists of a series
of completely independent Atom Entries, each of which can be
interpreted in isolation of any others as well as of the Atom
Feed Document that they are found in (modulo Person Construct
inheritance). This would explicitly allow consumers to rely on
this atomicity (pun intended), thus preventing any extensions
from crossing these boundaries.

This goes beyond the mere interchange of messages to a definition
of a standardised model, though as you can see, it’s a very loose
one. I contend it is also the model used implicitly by any useful
aggregator which tracks feed content over time.

Section 6.4 is more myopic and simultaneously more presbyopic
than that.

This omission shouldn’t matter much in practice. RFC 4287 enables
such a world view implicitly anyway (eg. by only allowing feed
metadata to appear at the top of a Feed Document and declining to
assign any significance to the order of entries). Extensions
which require considering an Atom Feed Document as an overall
unit rather than as a collection will hopefully fail to gain much
acceptance by virtue of high burden on implementors. But being
explicit about this model would have made RFC 4287 a better spec.

Regards,

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 24 May 2006 11:26:57 +0100

> aggregator which tracks feed content over time.

I think this group would not have been able to agree on what "a little 
more" was, the current situation makes sense to me.  IMO, the Infoset is 
no basis for a model; it's there for spec writers and marshalling off 
the wire.

cheers
Bill

---

From: David Powell <[email-masked]>
Date: Fri, 26 May 2006 00:52:37 +0100

> elements and attributes with about the same degree of difficulty.

What Aristotle said.  Yes, I agree, but debate over elements vs
attributes in generic XML isn't relevant.

> If software arbitrarily discards markup because the markup

I'm a bit surprised that you're saying this. I'm not sure why you
think it is non-conformant to discard extensions. RFC4287 doesn't
describe any conformance criteria for Atom intermediaries.

Over on atom-protocol, there were a number of implementors who are
ignoring/rewriting client-supplied atom:ids - about the most
fundamental way that you could possibly change an atom document - and
you didn't seem to disapprove of this?

People have also said in the past that they planned not to preserve
extensions, and I don't remember there being many objections. If it is
non-conformant and non-interoperable to discard extensions, then why
doesn't APP prohibit it?

> Extension elements also, as noted above, have *no normative effect*.

I don't know what "no normative effect" means.

> dreamed up, you cannot expect to achieve interoperability.

But every implementor is dreaming up ex post facto models.

> in the marketplace, whether those are elements or attributes.

It is easier to support extensibility in 3 places, than on every
possible element in the document. Storing entry extensions in a
database table is possible, storing atom:updated attributes, is
getting silly.

> Yes, and interoperability is based on the normative rules in RFC4287,

Wrong (in my opinion).

There are no normative rules for the behaviour of Atom intermediaries.

Given the absence of such rules, the next best way to ensure
interoperability to understand the typical behaviour of Atom
implementations: the fact that it is easier for some implementations
to support "Extension Elements" in the 3 defined extension points than
foreign attributes on every element in an Atom document; that this
translates to more implementations supporting extension elements than
attributes; and that this implies that an extension would be more
interoperable if it chooses Section 6.4 markup over undefined foreign
markup.

-- 
Dave

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 30 May 2006 12:10:09 -0700

> to store these and make them retrievable will quickly be seen as  

I find this to be a pretty compelling argument.  Unless RFC4287 were  
rewritten (with a time machine, perhaps) to forbid extensions in  
attributes, extension writers will occasionally put data in  
attributes, and the libraries will have to deal with this, regardless  
of how the Thread proposal works.

Lisa

---

From: "Robert Sayre" <[email-masked]>
Date: Tue, 30 May 2006 15:46:58 -0400

On 5/30/06, Lisa Dusseault <[email-masked]> wrote:
> I find this to be a pretty compelling argument.

I don't find Tim's argument particularly compelling. It's crystal ball
stuff, and implementations are free to ignore *any* part of an Atom
document. In this case, it's another case of a WG member claiming
something is broken without a shred of spec text to back it up. If Tim
and others want that to be true, they have an RFC to revise.

-- 

Robert Sayre

---

From: James M Snell <[email-masked]>
Date: Tue, 30 May 2006 13:05:52 -0700

> something is broken without a shred of spec text to back it up. If Tim

The exact same can be said of the argument that the use of extension
attributes is broken.  There's not a shred of spec text to back it up.

> and others want that to be true, they have an RFC to revise.

The spec is clear.  Extension attributes are allowed by the spec.
Implementations that do not support extension attributes are choosing
not to support a feature allowed by the spec.  Whether that makes those
implementations "broken" or not is debatable.  Personally, I don't see
them as "broken", I just see them as extremely short-sighted.

- James

---

From: "Robert Sayre" <[email-masked]>
Date: Tue, 30 May 2006 16:10:17 -0400

> attributes is broken.  There's not a shred of spec text to back it up.

I didn't say the use of extension attributes is broken. I said your
extension has no reason to use them, remember? You never gave a
technical reason for the change between last call and the previous
version.

> Personally, I don't see them as "broken", I just see them as extremely short-sighted.

That's how I see your extension.

Hey, maybe you could do RFC4287bis as an individual submission!

-- 

Robert Sayre