Re: Feed Thread Draft Updated

[A. Pagaltzis]

* David Powell <[EMAIL PROTECTED]> [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
> links will be able to manage addition of the counts if
> necessary.

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,
-- 
Aristotle Pagaltzis // 

Re: Feed Thread Draft Updated

[David Powell]

Saturday, April 22, 2006, 1:53:26 AM, James M Snell wrote:

> So this is what I've got:

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

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.

> 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.

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

> 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.

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.)

> Does this work?

> - James

-- 
Dave

Re: Feed Thread Draft Updated

[M. David Peterson]

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

On 4/21/06, James M Snell <[EMAIL PROTECTED]> wrote:
>
> The feedvalidator really does need a "ValidButPositivelyIdiotic" warning.
>
> - James
>
> Eric Scheid wrote:
> > On 22/4/06 10:53 AM, "James M Snell" <[EMAIL PROTECTED]> wrote:
> >
> >> 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
> >
> > Would this be considered a "match"?
> >
> >> href="comments"
> > xml:base="/06/04/21/blah/" />
> >>  updated="...">5
> >
> > You just know there'll be a few idiots that will try that on.
> >
> > e.
> >
> >
>
>


--


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

Re: Feed Thread Draft Updated

[James M Snell]

The feedvalidator really does need a "ValidButPositivelyIdiotic" warning.

- James

Eric Scheid wrote:
> On 22/4/06 10:53 AM, "James M Snell" <[EMAIL PROTECTED]> wrote:
> 
>> 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
> 
> Would this be considered a "match"?
> 
>href="comments"
> xml:base="/06/04/21/blah/" />
> updated="...">5
> 
> You just know there'll be a few idiots that will try that on.
> 
> e.
> 
> 

Re: Feed Thread Draft Updated

[Eric Scheid]

On 22/4/06 10:53 AM, "James M Snell" <[EMAIL PROTECTED]> wrote:

> 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

Would this be considered a "match"?

  
  5

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

e.

Re: Feed Thread Draft Updated

[A. Pagaltzis]

* James M Snell <[EMAIL PROTECTED]> [2006-04-22 03:05]:
>  ... 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…

> To be absolutely honest, David's comments here [1] really got me
> 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,
-- 
Aristotle Pagaltzis // 

Re: Feed Thread Draft Updated

[James M Snell]

 ... 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.:

  
  5

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

A. Pagaltzis wrote:
>[snip]
> 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:
> 
> 5
> 
> 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:
> 
> http://example.org/06/04/21/blah/comments"; 
> type="application/atom+xml" />
> http://example.org/06/04/21/blah/trackbacks"; 
> type="application/atom+xml" />
> http://example.org/06/04/21/blah/comments"; 
> updated="2006-04-22T00:50:55+0200">4
> http://example.org/06/04/21/blah/trackbacks"; 
> updated="2006-04-21T22:21:37+0200">1
> 5
> 
> 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.
> 
>>d2:
>>
>>
>>
>>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.
> 
> -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,

Re: Feed Thread Draft Updated

[A. Pagaltzis]

* James M Snell <[EMAIL PROTECTED]> [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.

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

+0

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

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

+0.5

> d. Create a supplemental extension element
> 
>d1:
>
>
> 
>Where the ref attribute in  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.

+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:

5

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:

http://example.org/06/04/21/blah/comments"; 
type="application/atom+xml" />
http://example.org/06/04/21/blah/trackbacks"; 
type="application/atom+xml" />
http://example.org/06/04/21/blah/comments"; 
updated="2006-04-22T00:50:55+0200">4
http://example.org/06/04/21/blah/trackbacks"; 
updated="2006-04-21T22:21:37+0200">1
5

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.

>d2:
>
>
> 
>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.

-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,
-- 
Aristotle Pagaltzis // 

Re: Feed Thread Draft Updated

[Robert Sayre]

> James M Snell wrote:
>> Maybe, but given that WG messed up in not making the link element
>> 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

RE: Feed Thread Draft Updated

[Byrne Reese]

Returning from the beyond to cast a vote.

> James M Snell wrote:
> > a. Status quo. Leave things the way they are in the current draft

+1

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

-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. :)

> > d. Create a supplemental extension element

+0

Re: Feed Thread Draft Updated

[James Holderness]

James M Snell wrote:

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


+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

Re: Feed Thread Draft Updated

[A. Pagaltzis]

* David Powell <[EMAIL PROTECTED]> [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,
-- 
Aristotle Pagaltzis // 

Re: Feed Thread Draft Updated

[Eric Scheid]

On 13/4/06 6:59 PM, "David Powell" <[EMAIL PROTECTED]> wrote:

> 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)

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.

RE: Feed Thread Draft Updated

[Kirit Sælensminde]

See below...

http://www.kirit.com/

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:owner-atom-
> [EMAIL PROTECTED] On Behalf Of David Powell
> Sent: Thursday, April 13, 2006 4:49 PM
> To: Thomas Broyer
> Cc: Atom-Syntax
> Subject: Re: Feed Thread Draft Updated
> 
> 
> 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.

This depends on what sort of application you're building though. As a content 
publisher it doesn't really make that much difference as I will choose the 
markup that I feels best represents my internal data and models (and which I 
think will be best understood and most relevant to my audience).

If I am writing a desktop display tool then I'll work out which extensions are 
going to be of most use to somebody reading the contents of the feed. I'll 
probably ignore all sorts of things that are not relevant or I don't 
understand. My OO model is going to reflect what I'm going to draw on screen 
and so long as I can map incoming feeds to show them it's fine.

The problem comes where I'm writing something that's going to repackage feeds. 
If I make the decision to preserve as much of the original markup then I have 
to allow for that in my internal models. I may however take the view that the 
audience that I'm repackaging the feeds for want me to transform it and that's 
part of my service.

If I as a publisher have chosen to use some weird markup that maybe I've 
invented then that's my lookout. I should really make sure though that the feed 
is understandable at least on a basic level with just core Atom markup. If I 
can't do that then Atom may not be the best medium for me to publish in.


K

Re: Feed Thread Draft Updated

[David Powell]

Thursday, April 13, 2006, 8:24:48 AM, Thomas Broyer wrote:

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

> -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

Re: Feed Thread Draft Updated

[James Holderness]

David Powell wrote:

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)


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

Re: Feed Thread Draft Updated

[David Powell]

Thursday, April 13, 2006, 6:11:32 AM, Eric Scheid wrote:

> 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:

>  bar="opaque-string
>qaz="opaque-string"
>zak="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

Re: Feed Thread Draft Updated

[Eric Scheid]

On 13/4/06 8:02 AM, "David Powell" <[EMAIL PROTECTED]> wrote:

> 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).

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:

 

e.

Feed Thread Draft Updated

[Thomas Broyer]

2006/4/13, James M Snell <[EMAIL PROTECTED]>:
> 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.

+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
> type="..."
> hreflang="..."
> title="..."
> count="..."
> when="..." />

-0.5, it *is* a link

> d. Create a supplemental extension element
>
>d1:
>
>
>
>Where the ref attribute in  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.

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

>d2:
>
>
>
>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.

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 [EMAIL PROTECTED]). In this case, having a
@count per link is IMO somewhat important. So -1.

--
Thomas Broyer

Re: Feed Thread Draft Updated

[James M Snell]

A. Pagaltzis wrote:
>[snip]
> 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,

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
   

d. Create a supplemental extension element

   d1:
   
   

   Where the ref attribute in  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:
   
   

   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

Re: Feed Thread Draft Updated

[A. Pagaltzis]

* James M Snell <[EMAIL PROTECTED]> [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
> [EMAIL PROTECTED] 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 [EMAIL PROTECTED]"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,
-- 
Aristotle Pagaltzis // 

Re: Feed Thread Draft Updated

[James M Snell]

A. Pagaltzis wrote:
> * David Powell <[EMAIL PROTECTED]> [2006-04-13 00:15]:
>> This seems to be the wrong priority to me.
> 
> 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.

>[snip]
> 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.
>

With in-reply-to, the key issue that swung the argument in favor of a
new extension element was whether or not the [EMAIL PROTECTED] 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 [EMAIL PROTECTED]"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 [EMAIL PROTECTED]"replies"],
even if those implementations do choose to ignore-and-discard unknown
foreign markup that happens to appear in the link.

> 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.
> 
> 

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

Re: Feed Thread Draft Updated

[M. David Peterson]

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 PROTECTED]> wrote:
* David Powell <[EMAIL PROTECTED]> [2006-04-13 00:15]:> This seems to be the wrong priority to me.Convincing arguments, IMHO; +1.James:
As regards Robert's vociferous comments, you have to acknowledgethat while the rest of the draft was hashed out in severaliterations, these `thr:count` and `thr:when` things snuck in at alate stage without any discussion.
And, as regards David's stance, I think it warrants a reminderthat `thr:in-reply-to` started life as as an `in-reply-to` linkrelation as well, but we moved away from that because all of ourattempts 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 forAtom extensions:Trying to extend `atom:link` is bad. If you need moresemantics than afforded to it by RFC 4287, you should
clone it and tweak the copy.Regards,--Aristotle Pagaltzis // -- 
M. David Petersonhttp://www.xsltblog.com/

Re: Feed Thread Draft Updated

[A. Pagaltzis]

* David Powell <[EMAIL PROTECTED]> [2006-04-13 00:15]:
> 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 // 

Re: Feed Thread Draft Updated

[David Powell]

Tuesday, April 11, 2006, 9:20:32 PM, James M Snell wrote:

> 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."

[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  with an otherwise identical
 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:
 http://www.example.org/mycommentsfeed.xml";
   count="10"
   when="2006-02-20T00:00:00Z" />

instead of:

 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

Re: Feed Thread Draft Updated

[James M Snell]

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:
> 
> James M Snell wrote:
>>> 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.
> 
> 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
> 
> 

Re: Feed Thread Draft Updated

[James Holderness]

James M Snell wrote:

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.


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

Re: Feed Thread Draft Updated

[James M Snell]

James Holderness wrote:
>[snip]
> 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)
> 

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

Re: Feed Thread Draft Updated

[James Holderness]

James M Snell wrote:

The Feed Thread draft has been updated.

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

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.


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

Feed Thread Draft Updated

[James M Snell]

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