Subject: Feed Thread Draft Updated

From: James M Snell <[email-masked]>
Date: Tue, 11 Apr 2006 13:20:32 -0700

The Feed Thread draft has been updated.

http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-07.txt

Among various editorial changes, the in-reply-to id attribute is now
called "ref".

I also added a new warning for implementors: "Implementors should note
that while the Atom Syndication Format does not forbid the inclusion of
namespaced extension attributes on the Atom link element, neither does
is explicitly allow for such extensions.  The result of this is that the
thr:count and thr:when attributes fall outside of the guidelines for
Atom extensions as defined in Section 6 of [RFC4287] and may not be
supported by all Atom implementations."

There are a couple of typos, most significantly is a ? mark in the
definition of the ref attribute on in-reply-to.  It's not optional.

I am an absolutely terrible proofreader so I'd really appreciate it if
someone could do a quick scan over the current doc to find the typos
that I know must be scattered throughout.

- James

---

From: "James Holderness" <[email-masked]>
Date: Tue, 11 Apr 2006 23:27:16 +0200

> that I know must be scattered throughout.

Section 4, paragraph 1:
"into a separate feed document" (singular document)
"its value is assumed" (no apostrophe)

Section 4, last paragraph:
"neither does it explicitly allow" (is -> it)

Section 6:
"Security considerations: (see section 5)" (6 -> 5)

Not a proofreading issue, but shouldn't section 5 say something about DOS 
attacks using replies links to third party servers? I wouldn't be surprised 
if some clients automatically subscribed to all replies links in a feed even 
if they were 100MB zip files on a completely different site.

Regards
James

---

From: James M Snell <[email-masked]>
Date: Tue, 11 Apr 2006 15:49:27 -0700

James Holderness wrote:
>[snip]

Fixed in the next draft. Thank you.

> Not a proofreading issue, but shouldn't section 5 say something about
> DOS attacks using replies links to third party servers? I wouldn't be
> surprised if some clients automatically subscribed to all replies links
> in a feed even if they were 100MB zip files on a completely different site.
> 

Hmm.. this problem would apply generally to all types of Atom link
wouldn't it?  In any case, it likely would be good to at least mention
that implementations should take care when using the replies link to
automatically subscribe to feeds.

- James

---

From: "James Holderness" <[email-masked]>
Date: Wed, 12 Apr 2006 01:35:10 +0200

> automatically subscribe to feeds.

I don't think it necessarily applies to all links, just those that are 
likely to be followed automatically. I'm fairly sure I've seen aggregators 
that have an option for automatically subscribing to wfw:commentRss links so 
I'm assuming they're likely to do the same for this extension. Enclosures 
are another link type where I would consider this an issue.

I didn't see anything mentioned in the security section of RFC4287 though, 
so maybe it's not such a big deal. Mark's feed history draft covers it, but 
it could be argued that the feed history links probably SHOULD be followed, 
whereas enclosure and replies links only MAY be followed.

Anyway I'm not really sure it's essential. I just thought I should mention 
it in case it's the kind of thing that causes problems for you when 
submitting to the IETF.

Regards
James

---

From: James M Snell <[email-masked]>
Date: Tue, 11 Apr 2006 17:18:09 -0700

Works for me.  I couldn't think of a better way to describe the concern
than what Mark included in his draft so I simply copied it verbatim.

Mark N: I hope you don't mind. :-)

- James

James Holderness wrote:
> likely to be followed automatically. I'm fairly sure I've seen
> aggregators that have an option for automatically subscribing to
> wfw:commentRss links so I'm assuming they're likely to do the same for
> this extension. Enclosures are another link type where I would consider
> this an issue.
> 
> I didn't see anything mentioned in the security section of RFC4287
> though, so maybe it's not such a big deal. Mark's feed history draft
> covers it, but it could be argued that the feed history links probably
> SHOULD be followed, whereas enclosure and replies links only MAY be
> followed.
> 
> Anyway I'm not really sure it's essential. I just thought I should
> mention it in case it's the kind of thing that causes problems for you
> when submitting to the IETF.
> 
> Regards
> James
> 
>

---

From: David Powell <[email-masked]>
Date: Wed, 12 Apr 2006 23:02:10 +0100

> supported by all Atom implementations."

[Apologies to everyone for flogging this dead horse some more. I'm
only doing this, because I care.]

I'll quote your argument from MDP's blog and comment here, rather than
on his dead comment thread, if that's ok:

> Ironically, the primary reason for using link for "replies" is
> because it makes very little sense to duplicate the function of the
> link element. I considered a thr:replies element. Ultimately, it
> would have looked and acted darn near identical to the atom:link
> element (with attributes like type, href, hreflang, etc). One needs
> to consider whether or not it makes sense to introduce a new
> namespaced extension element that duplicates the basic function of
> atom:link just to support the addition of two *optional* and *purely
> advisory* attributes.

You recognize the fact that adding non-standard attributes on
atom:link isn't going to be fully interoperable (that the thr:count
and thr:when attributes might not make it from producer to consumer
intact), but still prefer to make "replies" a link element on the
basis of style and convention.

This seems to be the wrong priority to me.
Replacing <atom:link rel="replies"> with an otherwise identical
<thr:replies> element would fix the interop problem, and wouldn't
introduce any other problems that I can think of. The only reason to
keep the current link element is because it somehow looks better, or
saves copy/pasting the relevant bits of the atom:link spec into the
draft.

In terms of the considerations to the interoperability of running
code, thr:replies seems to beat atom:link in every way. It even
manages to be more concise (you don't need the @rel), and you wouldn't
need to put thr:count and thr:when into a namespace (namespaced
attributes confuse people).

Eg:
         <thr:replies type="application/atom+xml"
               href="http://www.example.org/mycommentsfeed.xml"
               count="10"
               when="2006-02-20T00:00:00Z" />

instead of:

         <link rel="replies"
               type="application/atom+xml"
               href="http://www.example.org/mycommentsfeed.xml"
               thr:count="10"
               thr:when="2006-02-20T00:00:00Z" />

I don't really buy the justification that the attributes don't matter,
so it is ok if they get lost btw. If I was using an API that didn't
give access to the count attributes, I'd probably be a bit miffed, I'm
unlikely to say "oh it doesn't matter cause they were only advisory,
I'll just load the comments feed, parse the XML, etc, etc, instead".
Yes, thr:count is derived, so it isn't essential, but this doesn't
mean that it isn't useful. It is obviously useful, else it wouldn't be
in the draft.

-- 
Dave

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 13 Apr 2006 01:59:58 +0200

> This seems to be the wrong priority to me.

Convincing arguments, IMHO; +1.

James:

As regards Robert’s vociferous comments, you have to acknowledge
that while the rest of the draft was hashed out in several
iterations, these `thr:count` and `thr:when` things snuck in at a
late stage without any discussion.

And, as regards David’s stance, I think it warrants a reminder
that `thr:in-reply-to` started life as as an `in-reply-to` link
relation as well, but we moved away from that because all of our
attempts to twist Atom links into carrying all the additional
semantics we needed ended up looking funny.

So I would argue that the same appears to be a good idea for the
`replies` relation since it grew beyond the scope of Atom links.

I would even argue that what we are seeing here are really the
first observed instances of a general best practice pattern for
Atom extensions:

    Trying to extend `atom:link` is bad. If you need more
    semantics than afforded to it by RFC 4287, you should
    clone it and tweak the copy.

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

---

From: "M. David Peterson" <[email-masked]>
Date: Wed, 12 Apr 2006 19:48:57 -0600

Hey Folks,

Great discussion going on here...  Thanks! >
http://www.oreillynet.com/xml/blog/2006/04/the_power_of_the_people.html

On 4/12/06, A. Pagaltzis <[email-masked]> wrote:
> As regards Robert's vociferous comments, you have to acknowledge
> And, as regards David's stance, I think it warrants a reminder

--
<M:D/>

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

---

From: James M Snell <[email-masked]>
Date: Wed, 12 Apr 2006 19:01:02 -0700

> Convincing arguments, IMHO; +1.

Sorry, not convinced.  I never once claimed that the motivation for
using link was because it "looked" better.  What I did claim was that
there is little to no technical justification for exactly duplicating
the link element for the sole purpose of introducing two new optional
attributes.... especially when the Atom spec expressly *allows* for such
extensions.

> `replies` relation since it grew beyond the scope of Atom links.

With in-reply-to, the key issue that swung the argument in favor of a
new extension element was whether or not the link[@href] attribute value
could be an atom:id value or whether it had to be a dereferenceable URI.
 In other words, it was quite likely that ignorant implementations would
do the Wrong Thing with a link[@rel="in-reply-to"].

Big difference in this case.  There are no additional semantics that
make the replies link "look funny".  It *looks* like a link; smells like
a link; acts like a link; it *is* a link. The fact that that link MIGHT
have two additional pieces of metadata associated with it does not make
it any less of a link.

Further, there is likely zero chance that properly coded rfc4287
implementations will do the Wrong Thing with a link[@rel="replies"],
even if those implementations do choose to ignore-and-discard unknown
foreign markup that happens to appear in the link.

>     clone it and tweak the copy.

Not to be snarky, but that philosophy hasn't exactly worked out too well
in the past (e.g. the rss 2.0 description tag).

The Atom link element is well defined and does *everything* the replies
link requires, right on down to the undefinedAttribute* and the
definition of "unknown foreign markup".

Bottom line: I'd be far more inclined to either drop thr:when and
thr:count from the spec or document a clear caveat that the two
attributes are likely not to be supported in some implementations than I
would be to use anything other than link for replies.

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 13 Apr 2006 06:43:41 +0200

* James M Snell <[email-masked]> [2006-04-13 04:10]:
> What I did claim was that there is little to no technical
> justification for exactly duplicating the link element for the
> sole purpose of introducing two new optional attributes...

David countered that having this information is clearly useful,
else these attributes would not be in the spec, which means there
is a case to be made for making sure they’re available to all
clients, even those behind an API that only provides access to
Sec.6 extensions.

> With in-reply-to, the key issue that swung the argument in
> favor of a new extension element was whether or not the
> link[@href] attribute value could be an atom:id value or
> whether it had to be a dereferenceable URI. In other words, it
> was quite likely that ignorant implementations would do the
> Wrong Thing with a link[@rel="in-reply-to"].

My memory was different, so I went and re-read the threads.

The non-dereferencable URI issue was an important sideline, but
it was only a sideline in that discussion. If we were having that
discussion now, I agree that it would be a much bigger sticking
point, but back then, it was an also-ran.

The big debate which swayed the issue at the time was having a
mechanism for associating a source link with an in-reply-to link.
We were trying all sorts of funny combinations with things nested
inside the links or the links nested inside other things, IDREF
attributes, and what have you.

In the end, I put a big torch to my own proposition of an
`in-reply-to` link relation to end the madness:
http://www.imc.org/atom-syntax/mail-archive/msg16594.html

> Big difference in this case. There are no additional semantics
> that make the replies link "look funny".

It’s not nearly as funny-looking as that crazy in-reply-to
business we came up with back then, conceded.

> Not to be snarky, but that philosophy hasn't exactly worked out
> too well in the past (e.g. the rss 2.0 description tag).

But `description` can only appear once in an item, and therefore
there has to be some precedence matrix between it and its
derivatives. Not so with `atom:link` and clones, all of which may
appear any number of times in an entry, and thus pose no
precedence problem. In other words, comparing the two situations
is not quite fair.

> Bottom line: I'd be far more inclined to either drop thr:when
> and thr:count from the spec or document a clear caveat that the
> two attributes are likely not to be supported in some
> implementations than I would be to use anything other than link
> for replies.

Maybe we can think of other ways to expose this information so
that it fits the Atom extension model? Are those attributes
really the only possible approach to this issue?

Regards,

---

From: James M Snell <[email-masked]>
Date: Wed, 12 Apr 2006 23:54:32 -0700

> really the only possible approach to this issue?

Maybe, but given that WG messed up in not making the link element
formally extensible, it's not likely to be pretty.  Also, keep in mind
that the uglier and more complicated the "correct" approach looks, the
more implementors are going to gravitate towards less-than-correct
approaches that meet their immediate needs.

So, with that, let's catalog the options.

a. Status quo. Leave things the way they are in the current draft
   with a firm warning to implementors that not all atom impls
   will be capable of supporting them.

b. Drop thr:count and thr:when from the spec.

c. Create a new replies extension element
   <thr:replies href="..."
                type="..."
                hreflang="..."
                title="..."
                count="..."
                when="..." />

d. Create a supplemental extension element

   d1:
   <link rel="replies" href="..." />
   <thr:replies ref="..." count="..." when="..." />

   Where the ref attribute in <thr:replies /> is a
   unique identifier that can be matched to the
   resource linked by the replies link.  If only a
   single replies link is specified, ref can be
   omitted.  There could be one thr:replies for
   each replies link.

   d2:
   <link rel="replies" href="..." />
   <thr:replies count="..." when="..." />

   only one thr:replies would be specified regardless
   of the number of replies links. count would be
   reflective of the total number of known replies
   across all links.

Of the options above, I'm fine with (a) and (b) ...in that order

IMHO (c) is not a viable option, (d1) is ugly as hell and (d2)
sacrifices the use case for a cleaner implementation.

Please suggest additional options and/or arguments in-favor/against the
options above.

- James

---

From: "Thomas Broyer" <[email-masked]>
Date: Thu, 13 Apr 2006 09:24:48 +0200

>    will be capable of supporting them.

+1

> b. Drop thr:count and thr:when from the spec.

+0.5 (and let someone add that metadata later if needed, in the same
way as (a) or (d1) or maybe proposing something we haven't thought
about)

> c. Create a new replies extension element

-0.5, it *is* a link

>    omitted.  There could be one thr:replies for

-0.5, ugly
but that's probably what would better match today's approach (in "a" above)

>    reflective of the total number of known replies

If I understand correctly, the use case for multiple "replies" link
is, e.g., having a "comments" and a "trackbacks/pingbacks" feeds
(could be distinguished by link[@title]). In this case, having a
@count per link is IMO somewhat important. So -1.

--
Thomas Broyer

---

From: Eric Scheid <[email-masked]>
Date: Thu, 13 Apr 2006 15:11:32 +1000

> attributes confuse people).

atom:link beats thr:replies on the basis that I don't need to understand
what "replies" are to discover that there is a link from this thing to that
thing.

atom processors know what atom:link is, but it wouldn't know what to do with
this:

         <xyz:qwerty foo="opaque-string"
               bar="opaque-string
               qaz="opaque-string"
               zak="opaque-string" />

e.

---

From: David Powell <[email-masked]>
Date: Thu, 13 Apr 2006 09:59:17 +0100

>          <xyz:qwerty foo="opaque-string"

But what would processors do with an atom:link? Atom Protocol uses
"edit", there have been calls for a "stylesheet". Links aren't
necessarily things that you'd display to users (check HTML out for
examples of that: favicon, P3P, Atom/RSS, GRDDL)

-- 
Dave

---

From: "James Holderness" <[email-masked]>
Date: Thu, 13 Apr 2006 11:34:58 +0200

> examples of that: favicon, P3P, Atom/RSS, GRDDL)

Well if you've got a decent feed API (hint: not the Microsoft one) you could 
ask it for a list of links on an entry without it having to know what all 
the link types are, and without you having to parse the XML yourself. If it 
was a really nice API it might even provide you with a set of extension 
attributes included with each link.

Regards
James

---

From: David Powell <[email-masked]>
Date: Thu, 13 Apr 2006 10:49:06 +0100

> -0.5, it *is* a link

thr:in-reply-to is a "link" too. An extension element was used for
thr:in-reply-to, because atom:link wasn't up to the job. atom:link
isn't up to the job for "replies" either.

I think that slavishly adhering to convention, at the cost of
interoperability is unwise.

I'm bothered about this because I think requiring people to process
undefined foreign markup is harmful to Atom.

With something like an XHTML document, the only sensible way to
process it is by using XML tools. XPath, XSLT, whatever - they work
well.

With Atom, an "Atom Feed Document" alone isn't very useful. Almost all
applications will work in terms of Atom Feeds - streams of entries,
and feed metadata. To process this, you need to think of Atom in terms
of entities: Feeds and Entries, not a set of XML Feed documents.
Implementations are based on OO classes and databases, and model
entries in terms of titles, content, links, extensions etc. The Atom
RFC is clear enough, that you can model an Atom Feed in terms of OO
classes, rather than XML documents without losing any data.

This all falls apart when people sprinkle the XML with undefined
markup that can't be represented outside the context of an XML
document.

-- 
Dave

---

From: Eric Scheid <[email-masked]>
Date: Thu, 13 Apr 2006 20:56:04 +1000

> examples of that: favicon, P3P, Atom/RSS, GRDDL)

as I understand it, dereferencing the 'edit' link returns a representation
of the entry which is suitable for editing (ie. it contains all the bits
needed).

as to the other link types in html ... I hope we've learned something from
that experience since then.

e.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 13 Apr 2006 13:09:09 +0200

* David Powell <[email-masked]> [2006-04-13 11:10]:
> But what would processors do with an atom:link? Atom Protocol
> uses "edit", there have been calls for a "stylesheet". Links
> aren't necessarily things that you'd display to users (check
> HTML out for examples of that: favicon, P3P, Atom/RSS, GRDDL)

Isn’t that what the `type` attribute is for?

Regards,

---

From: "James Holderness" <[email-masked]>
Date: Mon, 17 Apr 2006 20:54:20 +0100

+1

> b. Drop thr:count and thr:when from the spec.

+0.5

> c. Create a new replies extension element

-1

> d. Create a supplemental extension element

+0

---

From: "Byrne Reese" <[email-masked]>
Date: Fri, 21 Apr 2006 17:39:18 -0400

Returning from the beyond to cast a vote.

+1

-1

I have yet to hear personally an argument compelling to me to believe
why these elements should be eliminated. Unless they violate an existing
specification, which they don't to my knowledge, I find these incredibly
useful. Furthermore, I am pretty sure James added these at [partially]
my request, so I feel it important for me to provide the use case that
was the catalyst for this feature.

A Six Apart partner (Friendster in this case) desired a way of keeping
tabs on what posts within TypePad were getting new comments, with the
purpose of being able to email its subscribers saying - "You have a new
comment on your blog", "or your friend has a new comment on their blog."

On one hand this partner could just grab each comments feed individually
and crunch the stats they needed that way, but their IDEAL solution
involved them being able to fetch a single document that contained this
information. The alternative: fetching a feed, then fetching the comment
feed for each entry, parsing those feeds and determining a) when the
last comment was, and how many comments there are in total seemed like
overkill to me

And I have to agree. There should be no need for a client to have to
fetch and parse so much XML on its own to get such simple meta data.
Thus my desire to have these added.

What was especially interesting about our implementation was that we did
not implement comment feeds themselves. We implemented comment meta data
only. You will not find comment feeds on Friendster, but you will find
an easy way for a client to extract meaningful data about comment
activity from the system. It was a light weight solution with minimal
impacts for us and Friendster alike.

Example:
http://byrnereese.blogs.friendster.com/my_blog/atom.xml 

> > c. Create a new replies extension element

-0.5

Given that we have an implementation in the wild I tend to say, "no, I
like it as-is." But I have no grounds to hold up progress on this draft
because of Six Apart's preference. But 1.5 million blogs using the
replies link relation ain't insignificant. :)

+0

---

From: "Robert Sayre" <[email-masked]>
Date: Fri, 21 Apr 2006 18:02:20 -0400

>> formally extensible, it's not likely to be pretty.

Nice one.

> > a. Status quo. Leave things the way they are in the current draft.

-1.

James M Snell wrote:
> None of the implementors I'm aware of are currently making use of
> multiple replies link relations

It doesn't work in the Windows Feed API, client implementors haven't
been too excited about it, and it's not based on existing practice. I
don't really have a problem parsing it, I just don't know what I would
do with a group of those figures, or why it's even needed.

> > b. Drop thr:count and thr:when from the spec.

+ 0.5. thr:when seems pretty useless.

> > d. Create a supplemental extension element

+1.

Robert Sayre

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sat, 22 Apr 2006 01:17:57 +0200

* James M Snell <[email-masked]> [2006-04-13 09:05]:
> Maybe, but given that WG messed up in not making the link
> element formally extensible, it's not likely to be pretty.

Yes. WGs mess up. It’s just life. In a perfect world, this would
be different, but Atom took long enough to ship. What we shipped
feels very solid and robust to me, despite the occasional hole or
oversight.

So let’s just accept that what we have is somewhat imperfect, and
try to get as close to pretty as we can within the constraints.

> Also, keep in mind that the uglier and more complicated the
> "correct" approach looks, the more implementors are going to
> gravitate towards less-than-correct approaches that meet their
> immediate needs.

I know.

> a. Status quo. Leave things the way they are in the current
>    draft with a firm warning to implementors that not all atom
>    impls will be capable of supporting them.

-0.5. As David and Byrne pointed out, having this information is
clearly useful, otherwise these attributes would not be part of
the spec; so it’s worth making an effort to make them available.

+0

Though -0.5 if that’s all that would happen. *Some* mechanism for
providing this information should be available.

+0.5

+0.5

I’d instead propose a `thr:count` element with content, with
attributes `ref` and `updated` (`when` is too vague, IMO; I’d
prefer names suggestive of RFC4287 vernacular, particularly when
the semantics are comparable). If `ref` is omitted, this is a
global reply count. If it is present, this is a local reply count
for that resource, and the content of the `ref` attribute must be
identical with the `href` attribute of the corresponding link.
`updated` is, of course, optional.

A single global reply count is always permitted, in addition to
local reply counts, of which there may be exactly one per
resource referenced in a `replies` link.

This reduces the typical use case to a single Simple Extension
Element:

    <thr:count>5</thr:count>

This accomodates developers with modest immediate needs neatly.

The most complex scenario then looks something like this, where
there are several additional Structured Extension Elements:

    <link rel="replies" href="http://example.org/06/04/21/blah/comments" type="application/atom+xml" />
    <link rel="replies" href="http://example.org/06/04/21/blah/trackbacks" type="application/atom+xml" />
    <thr:count ref="http://example.org/06/04/21/blah/comments" updated="2006-04-22T00:50:55+0200">4</thr:count>
    <thr:count ref="http://example.org/06/04/21/blah/trackbacks" updated="2006-04-21T22:21:37+0200">1</thr:count>
    <thr:count>5</thr:count>

It’s somewhat ugly, but I think I can stomach it.

How does that look?

So far I’m not decided about whether there should be any language
to suggest some interpretation of a discrepance between a global
reply count and the sum of local reply counts, but I’m leaning
strongly towards no. Since local reply counts would not have to
be given for *every* resource, any constraint that the sum of
local replies match up with global reply count would have to be
qualified to apply only when local reply counts are present for
*all* linked `replies` resources. So not only is it questionable
whether such a constraint would really be useful in the first
place, rather than an unnecessary burden, but it also would be
complex, and yet feeble. That makes it seem like a bad idea.

>    reflective of the total number of known replies

-1. Having per-link information allows mapping scenarios more
complex than the weblog model, such as a Usenet-ish landscape of
multiple related, but independent distributed feeds. I’d rather
not throw those out.

Regards,

---

From: James M Snell <[email-masked]>
Date: Fri, 21 Apr 2006 17:53:26 -0700

<grumble> ... I'm not really happy with it but this would work.

To be absolutely honest, David's comments here [1] really got me
thinking.  It's definitely worth a read and alone was sufficient to sway
me on this.  I don't like it; the use of the supplemental element is
ugly, but it's better than what's currently out there (e.g. slash:count)
and at the very least preserves the use case.

So this is what I've got:

 count = element thr:count {
   attribute xml:base { atomUri }?,
   attribute ref { atomUri }?,
   attribute updated { date-time }?,
   ( nonNegativeInteger )
 }

The value of ref is the href of a replies link appearing in the
entry/feed/source.  Where that gets nasty, of course, is when the href
is relative and xml:base is being used to set the Base URI.  Publisher
would need to make sure that the href/ref combo match up properly, e.g.:

  <link rel="replies"
        href="comments"
        xml:base="/06/04/21/blah/" />
  <thr:count ref="comments"
             xml:base="/06/04/21/blah/"
             updated="...">5</thr:count>

The updated spec would have an appendix that would explain that previous
versions of the extension defined the attributes and that some
implementations have been deployed that use the attributes.  The spec
will indicate that those attributes are deprecated in favor of the
thr:count element but that feed consumers have the discretion of whether
or not to support them.

Does this work?

- James

[1]http://www.oreillynet.com/xml/blog/2006/04/if_its_not_broken_dont_fix_it.html#comment-25193

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sat, 22 Apr 2006 03:44:59 +0200

> <grumble> ... I'm not really happy with it but this would work.

That’s roughly how I feel about it. :-)

It has in fact been the theme all throughout the Thread extension
development discussion…

> thinking.

Yeah, same here. Credit for my proposition really goes to him,
because his arguments about this matter (not just there, but
taken in entirety) where what drove it.

> I don't like it; the use of the supplemental element is ugly,

Yeah; well sorta: it’s specifically goobering up the document
with duplicate data in the necessary `ref` attributes that annoys
me. But I can’t think of any prettier approach that satisfies all
design goals as per David’s argument.

> Where that gets nasty, of course, is when the href is relative
> and xml:base is being used to set the Base URI.

Augh. Nasty indeed. However, it doesn’t concern me much, because
in Atom, `atom:link` has no children and only a single
URI-carrying attribution. Extensions will probably avoid adding
namespaced attributes or elements to it (cf. current discussion).
This means there’s little reason to apply an `xml:base` to an
individual `atom:link`.

> The updated spec would have an appendix that would explain that
> previous versions of the extension defined the attributes and
> that some implementations have been deployed that use the
> attributes. The spec will indicate that those attributes are
> deprecated in favor of the thr:count element but that feed
> consumers have the discretion of whether or not to support
> them.

I feel uncomfortable about it being codified for “eternity.”
There are still Atom 0.2 feeds in the wild, even though they’re
extremely rare. And we’re not seeing the end of Atom 0.3 anytime
soon. With that experience in mind I’d really prefer that the
previous approach not be legitimised even slightly, because
that’s likely to lead consumer developers to feel that they need
to support the old approach, and might lead publishers to probe
that support. So I’d prefer that there be some pressure for the
old approach to die quickly before it gets implemented in enough
venues for the Atom 0.3 Effect to set in.

I understand why you want it, though.

-0.5, I suppose?

I don’t know what to say about this.

Regards,

---

From: Eric Scheid <[email-masked]>
Date: Sat, 22 Apr 2006 14:44:45 +1000

On 22/4/06 10:53 AM, "James M Snell" <[email-masked]> wrote:

> Where that gets nasty, of course, is when the href
> would need to make sure that the href/ref combo match up properly

Would this be considered a "match"?

  <link rel="replies"
        href="comments"
        xml:base="/06/04/21/blah/" />
  <thr:count ref="/06/04/21/blah/comments"
             updated="...">5</thr:count>

You just know there'll be a few idiots that will try that on.

e.

---

From: James M Snell <[email-masked]>
Date: Fri, 21 Apr 2006 22:10:33 -0700

The feedvalidator really does need a "ValidButPositivelyIdiotic" warning.

- James

---

From: "M. David Peterson" <[email-masked]>
Date: Sat, 22 Apr 2006 01:11:22 -0600

That, or "You lied to me when you told me this was a web feed!"

(credit: 'href (http://plasmasturm.org/code/))

"A friend of mine in a compiler writing class produced a compiler with
one error message 'you lied to me when you told me this was a
program'.
– Pete Fenelon

--
<M:D/>

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

---

From: David Powell <[email-masked]>
Date: Thu, 27 Apr 2006 10:59:58 +0100

>    attribute updated { date-time }?,

I think that is ok.

Aristotle's suggestion is ok, in that it saves a bit of typing in the
common case where there is only one link - but in the case where there
is more than one link, a combined count seems pretty useless: if there
are multiple comment links, then either the consumer can cope with
them and process both the links and counts, or the consumer can't cope
with them and can only process the combined count - but the count
alone without any links to reach the comments isn't very useful, so
why bother with it - consumers that can cope with multiple comments
links will be able to manage addition of the counts if necessary.

A variation would be to go with your proposal, but to say that ref is
optional if there is only one comments link, but would that be
fragile?  People would have to remember to fix things up if they added
extra comment links - but is that going to be a common occurrence?
And implementations that add comment links will presumably be aware of
the semantics of comment links, and will therefore know about the need
to add missing refs?

Anyway, I think that any of these options is better than the current
situation.

> is relative and xml:base is being used to set the Base URI.

xml:base always gets nasty, but I don't see it as being a big problem
in this case.

> thr:count element but that feed consumers have the discretion of whether

Maintaining compatibility with an expired Internet Draft?  I don't
really support that.  Is it really needed:

Stage 1: Implementation X has no support for FTE
Stage 2: Implementation X supports obsolete draft of FTE
Stage 3: Implementation X supports final version of FTE

Nobody is going to consider the obsolete form to be invalid. All that
would happen if consumers don't support it, is that they won't see the
thread counts. This isn't a big deal, as before the implementations
had implemented support for FTE consumers wouldn't see the thread
counts anyway. Eventually those implementations that support the
obsolete form will be updated, and consumers will be able to process
the thread counts.

(I think the moral of this story is to, in future, not to specify
IANA-namespaced link rel until a specification has been finalised.
During development there are bound to be changes, and IANA links don't
allow versioning, or DO-NOT-DEPLOY banners in the URI (like the one we
put in Atom draft namespace). Although, to be honest, I'm amazed if
there is any real reluctance to make breaking changes to an Internet
Draft.)

-- 
Dave

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 27 Apr 2006 18:24:17 +0200

* David Powell <[email-masked]> [2006-04-27 12:10]:
> Aristotle's suggestion is ok, in that it saves a bit of typing
> in the common case where there is only one link - but in the
> case where there is more than one link, a combined count seems
> pretty useless: if there are multiple comment links, then
> either the consumer can cope with them and process both the
> links and counts, or the consumer can't cope with them and can
> only process the combined count - but the count alone without
> any links to reach the comments isn't very useful, so why
> bother with it - consumers that can cope with multiple comments

I don’t think it’s that useless, actually. One case I can think
of is where several comment feeds exist, where some comments are
duplicated in multiple feeds, but others are not. In that case,
the sum of local counts will be greater than the global count. I
expect that in practice, if a global count is present, it will
turn out to be the most precise count available, whereas there’s
nothing you could infer from a sum of local counts. (That does
not change the fact that all counts remain advisory, of course.)

Regards,