Subject: Atom Thread Feed syntax

From: Sylvain Hellegouarch <[email-masked]>
Date: Thu, 16 Mar 2006 15:50:48 +0100

Hi everyone,

I was reading the Atom Feed Thread draft [1] yesterday and I ran into a 
problem as I described in my blog [2]. To recap the 'in-reply-to' 
element defined in that specification takes an 'id' attribute that 
specifies /the universally unique identifier of the resource being 
responded to/.

Calling such an attribute 'id' is a mistake in my opinion as it confuses 
with the actual ID of the element itself within the XML document it 
belongs to and it makes impossible for another element within the 
document to have the same value as an 'id'. I would rather move the 
content of that attribute as a text element of the 'in-reply-to' element 
(as does the atom:id element).

Thoughts?
- Sylvain

[1] 
http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-05.txt
[2] http://www.defuze.org/archives/2006/03/14/about-atom-feed-threads

---

From: "Thomas Broyer" <[email-masked]>
Date: Thu, 16 Mar 2006 17:28:47 +0100

2006/3/16, Sylvain Hellegouarch <[email-masked]>:
> belongs to

It could lead to confusion, but as Atom doesn't define such an
attribute in its own namespace (or on elements in its own namespace)
and as no other extension that I know of do that either, I don't think
it really matters…

> and it makes impossible for another element within the document to
> have the same value as an 'id'.

In your blog, you actually wrote:
> The other problem I have with naming this attribute id is that no other
> element of the document can use the same attribute name and attribute
> value since that within an XML document, these are unique (unless I am
> mistaken of course).

I'm sorry to have to tell you that you *are* mistaken…

Having an attribute named "id" doesn't make it an "ID" (in the sense
of a unique identifier throughout the document, such as the ID type in
a DTD of xs:ID in XMLSchema), otherwise:
 - you wouldn't have to declare them explicitely in your DTDs and
there wouldn't be a need for an ID (resp. xs:ID) type in DTD (resp.
XMLSchema)
 - the validity constraint "One ID Per Element Type"
[http://www.w3.org/TR/REC-xml/#one-id-per-el] could never be met as
soon as you'd declare an ID attribute with a name different from "id"
 - there wouldn't have been a need for xml:id [http://www.w3.org/TR/xml-id/]

> I would rather move the content of that attribute as a text element of the
> 'in-reply-to' element (as does the atom:id element).

Eventually, I'd rather rename it to resource-id…

--
Thomas Broyer

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Thu, 16 Mar 2006 16:44:04 +0100

Hello Thomas,

> and as no other extension that I know of do that either, I don't think

You are right Atom does not define such an attribute but I'd be happier 
if extensions could follow Atom conventions as well. Atom sets the 
atom:id value not as in an attribute of atom:id but as its content. Why 
not following the convention in the first place?
Besides the fact there is no other extension to do so as of yet is quite 
irrelevant to me. Atom extensions are fairly young and hopefully they'll 
be more and more spreaded.

> [http://www.w3.org/TR/xml-id/]
Again this is a matter of convention in my opinion. When reading an XML 
document I don't want to be obliged to think about the actual meaning of 
an id attribute. You are indeed right (and thank you for explaining it 
to me) in terms of specification but conventions are often as important. 
Specially for people like me who are not XML guru.
Thanks for your feedback by the way :)

- Sylvain

---

From: "Thomas Broyer" <[email-masked]>
Date: Thu, 16 Mar 2006 20:03:27 +0100

> not following the convention in the first place?

Because they don't deserve the same role. atom:id gives the identifier
of the resource _described_ by the containing element, while
thr:in-reply-to/@id gives the identifier of the resource _referenced_
by the containing element (or, actually, gives an identifier _as a
reference_ to this resource). In that sense, thr:in-reply-to deserves
the same role as @href. If you get back to previous versions of the
threading extension, you'll see that it had been proposed that there
would only be @href, whether or not the given IRI were to be
dereferenced (e.g. by making an HTTP request) or just used as a
globally unique identifier. This has been worked out because a) people
(including me) wanted that these roles (retrieving vs. identifying) be
clearly distinguished and b) there wouldn't then have a mean to give
both the resource identifier and an IRI where to retrieve a copy of
it.

> > a DTD of xs:ID in XMLSchema), […]
>

Well, I wouldn't describe myself as an XML guru either ;-)

--
Thomas Broyer

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 17 Mar 2006 01:12:16 +0100

* Thomas Broyer <[email-masked]> [2006-03-16 20:15]:
>> Atom sets the atom:id value not as in an attribute of atom:id
>> but as its content. Why not following the convention in the
>> first place?
>
>Because they don't deserve the same role. atom:id gives the
>identifier of the resource _described_ by the containing
>element, while thr:in-reply-to/@id gives the identifier of the
>resource _referenced_ by the containing element (or, actually,
>gives an identifier _as a reference_ to this resource). In that
>sense, thr:in-reply-to deserves the same role as @href.

+1

* Thomas Broyer <[email-masked]> [2006-03-16 17:40]:
>> I would rather move the content of that attribute as a text
>> element of the 'in-reply-to' element (as does the atom:id
>> element).
>

Considering the above-mentioned symmetry with @href, I’m coming
around to whose-ever view it was that this attribute should be
called @ref for balance.

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

---

From: Andreas Sewe <[email-masked]>
Date: Fri, 17 Mar 2006 13:58:39 +0100

> Thomas Broyer <[email-masked]>:
>> Sylvain Hellegouarch <[email-masked]>:

I raised a similar issue regarding James Snell's Feed Rank I-D where a
ranking:scheme element has an @id attribute containing a IRI. In this
case the attribute is not used as a reference to another element,
though, but as an identifier of the ranking:scheme itself. (ranking:rank
elements refer to ranking:schemes via a @scheme attribute, which
contains the identifying IRI in question.)

In this case I think the analogy with atom:entry or atom:feed is
justified, so one conceivably could have something like the following:

<ranking:scheme ...>
   <ranking:id>http://example.org/five-stars</ranking:scheme>
</ranking:scheme>

(In a mail James Snell proposed changing @id to @name, instead.)

> around to whose-ever view it was that this attribute should be called
> @ref for balance.

But the issue raised by the OP is subtly different from the Feed Rank
one, since the Feed Rank I-D uses @id to label a ranking:scheme, whereas
the Feed Thread I-D uses @id to link to an atom:entry. In the latter
case the analogy to atom:id is IMHO unjustified, since atom:id serves as
a label, not a link.

@ref, however, sounds like an entirely reasonable name for such an
attribute.

Just my 2 Zorkmids.

Andreas Sewe

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Fri, 17 Mar 2006 15:28:34 +0100

> around to whose-ever view it was that this attribute should be
+1 for @ref as well.

---

From: James M Snell <[email-masked]>
Date: Fri, 17 Mar 2006 08:07:21 -0800

> @ref, however, sounds like an entirely reasonable name for such an

I'm coming around to this view as well.  On the downside, there are
implementations of the draft that are being prepared now, I will ping
the folks who I know are implementing and see if a name change for this
attribute would cause any inconvenience.

- James

---

From: James M Snell <[email-masked]>
Date: Thu, 23 Mar 2006 13:39:09 -0800

Just wanted to follow through on this for everyone.  Given that there
are vendors getting ready to ship code based on the current rev of the
spec, I'm *not* going to rename the "id" attribute to "ref".  Yes, I
know that "id" is confusing to some folks, but we're just talking the
name of a single attribute and not a critical functional bug.  From this
point forward, only critical spec bugs will be fixed and I will be
submitting the spec for consideration as a standards track RFC in the
not too distant future.

- James

---

From: David Powell <[email-masked]>
Date: Fri, 24 Mar 2006 01:08:55 +0000

> submitting the spec for consideration as a standards track RFC in the

I'm more bothered about the use of undefined markup on the link
element. I know, I know, I keep going on and on about this, but I keep
seeing more drafts that do the same thing and it isn't just a
theoretical problem: Windows Feed Platform does not preserve arbitrary
markup other than proper extension elements. Other feed stores and
servers are likely to do the same (justifiably IMO).

The abandonment of extension constructs in favour of undefined markup
by this draft, and other draft-*-atompub-* drafts would be an
interoperability concern if these drafts were deployed. If you want to
extend Atom, use Extension Elements.

-- 
Dave

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 24 Mar 2006 03:31:17 +0100

* David Powell <[email-masked]> [2006-03-24 02:20]:
>The abandonment of extension constructs in favour of undefined
>markup by this draft, and other draft-*-atompub-* drafts would
>be an interoperability concern if these drafts were deployed. If
>you want to extend Atom, use Extension Elements.

I don’t follow. Please explain how these drafts fail to satisfy
the criteria in Section 6.4.2, Structured Extension Elements.

Regards,

---

From: James M Snell <[email-masked]>
Date: Thu, 23 Mar 2006 19:28:02 -0800

I believe the concern is over the thr:count and thr:when attributes for
the replies link relation, both of which are optional, and both of which
provide what I consider to be extra information.  In other words, it's
ok if an implementation drops them.  The important bit is the
in-reply-to element and the replies link rel, both of which fall within
the bounds of the Atom extension model.

- James

---

From: James M Snell <[email-masked]>
Date: Thu, 23 Mar 2006 20:51:50 -0800

David Powell wrote:
>[snip]

I'm most certainly not abandoning the extension constructs.  One of the
motivations for walking these extension specs through the I-D and
eventually standards-track process is so that they get their own RFC
number.  Implementations that choose to support the extension can point
to RFC4287 *and* RFCwhatever and say, "I support both".  If an
implementation only says "I support RFC4287" and doesn't say anything
about RFCwhatever, it's pretty clear what the result would be.

The most an RFC4287 implementation should be expected to do is adhere to
the defined extension model.  If that implementation also chooses to
support other RFC's that go beyond that extension model, so be it.

That said, the critical parts of the Feed Thread draft (the in-reply-to
element and the replies link rel) follow the guidelines of the Atom
extension model.  That is, any RFC4287 implementation *should* be able
to do something with those elements (even if it's just preserving them).
 The optional parts of the extension (thr:count an thr:when) fall
outside of the Atom extension model.  That's ok.  Implementations can
choose to ignore those things, even completely drop them.

As for the other extension drafts I put out, keep in mind that most
should be considered strictly experimental at this time.  That said,
there is really only one that really falls outside the extension model..
the Link Extensions draft [1]... which, by definition cannot adhere to
the extension model given the fact that Atom link elements are actually
not extensible.

[1]
http://www.ietf.org/internet-drafts/draft-snell-atompub-link-extensions-02.txt

- James

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Fri, 24 Mar 2006 09:25:21 +0100

> submitting the spec for consideration as a standards track RFC in the
First of all thanks for the follow-up, this is appreciated. Now I do 
understand your motivation at keeping the name of the attribute and I 
also believe people that will be reading such feed won't make the 
mistake. Fir enough. It's not that a big deal... or is it?

I do find a bit hard to swallow though the "implemantators do it that 
way so let's not update the RFC" which is still a draft, even if an 
advanced one. I simply wonder what is worse, to annoy a few vendors now 
or a wider audience in the future.

Anyway, so be it. I won't argue and I leave you the final word on this 
one ;)

- Sylvain

---

From: David Powell <[email-masked]>
Date: Fri, 24 Mar 2006 17:33:05 +0000

Friday, March 24, 2006, 3:28:02 AM, James Snell wrote:

> ok if an implementation drops them.

Yeah I agree that an implementation losing those attributes wasn't
exactly life-threatening. But is it "*ok* if an implementation drops
them"? Will publishers think that it is ok if some infrastructure drop
those attributes? Will subscribers? Presumably publishers have spent
some effort adding those attributes to the feed, in the hope that
subscribers will get some benefit from them.

> The important bit is the in-reply-to element and the replies link
> rel, both of which fall within the bounds of the Atom extension
> model.

Yeah, I agree.

> support other RFC's that go beyond that extension model, so be it.

I find much of section 6 of RFC4287 a bit pointless.  It describes
these classes of extensions, and I just think - so what?.

I think it would be good to have a second draft which described a
number of conformance levels for feed infrastructure - things like the
handling, and preservation or not, of extensions. Then publishers
would know that if a popular infrastructure (Windows RSS, Rome,
Feedburner, APP implementations, etc) implements a given level of a
compliance, what to expect. It isn't always preferable for a feed to
reappear exactly as it was after travelling through an API or APP
store, much of the added value in implementations will come from the
transformations that they do. Even producing an archive feed, isn't
possible without a reasonable number of transformations (eg: storing
inherited constructs: author, base, lang, rights with the entry).

> choose to ignore those things, even completely drop them.

My hope is that implementors will be able to think of Atom in terms of
Entries, Feeds, and everything else; rather than in terms of XML, a
fragile document markup language.

> the extension model given the fact that Atom link elements are actually

I haven't looked at them all thoroughly. Do you want to extend link
elements rather than use extension elements in these cases because you
expect that link constructs are more likely to provide a UI in
implementations?

I suppose that there are workarounds, eg:

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

-- 
Dave

---

From: James M Snell <[email-masked]>
Date: Fri, 24 Mar 2006 09:51:23 -0800

> subscribers will get some benefit from them.

Yes, I think it's ok to drop them.  In fact, I'll likely add something
to the spec that discusses this issue.. specifically, that the thr:count
and thr:when attributes fall outside of the atom extensibility model and
may not be preserved by strictly compliant RFC4287 implementations.  In
other words, here they are, but use at your own risk.

> these classes of extensions, and I just think - so what?.

I agree, but...

> inherited constructs: author, base, lang, rights with the entry).

In my view of the current spec, Atom has two layers of extensibility.
One layer is defined in section 6.  The other is defined by XML.  A
strictly compliant RFC4287 implementation should only be expected to
comply with section 6, but that doesn't mean the implementation cannot
also support general extensibility on the XML layer.

> fragile document markup language.

Yep.  In the Atom implementation I've written, the entire XML infoset is
preserved with an Atom object model layered over the top.  E.g. code can
work with Feed, Entry, Link, etc.  As far as extensibility is concerned,
that Atom object model only exposes section 6 extensions.  If the app
developer wants to look at things from an XML perspective, they can peel
back a layer and work with the infoset directly.

> expect that link constructs are more likely to provide a UI in

I want to extend Link because there is little sense in reinventing it.
It would be silly for me to have a <foo:link /> sitting side by side
with <atom:link /> when both serve the same general purpose.  It was a
mistake not to make atom:link extensible per section 6.  However, this
is still XML and Atom allows undefined content and undefined attributes
on atom:link, so, I'm free to do what I want with atom:link so long as
I'm aware up front that what I'm doing falls outside the bounds of
Atom's section 6 extensibility model.

Personally, I think that folks will find in the long run that section 6
really is pointless.

>     href="http://www.example.org/mycommentsfeed.xml" />

Blech.  :-)

- James

---

From: James M Snell <[email-masked]>
Date: Fri, 24 Mar 2006 10:24:58 -0800

For me it's a matter of the fact that the spec has gone through 6
revisions and two design overhauls since it was first pitched.  It's
been out there for quite a while.  At some point, the design discussions
need to end and it needs to stablize so that folks can do something real
with it.  If, during that process, some folks get annoyed, so be it,
that's the nature of the game.  No spec is perfect, nor should we waste
our time trying to make them so.  Is the spec good enough?  I think so.
 Are there any functional bugs? I don't think so.  Can the spec text be
improved? Definitely, and I'll likely do so one more time between now
and when it's actually submitted for consideration as a standards track
RFC.

- James

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Fri, 24 Mar 2006 19:32:20 +0100

Hi James,
> that's the nature of the game.  
Well I find you a bit aggressive here I haven't said I was annoyed nor 
anybody else. I'm sorry for not being there during the first months 
you've put that draft in shape. There is no place I have seen where you 
said in the first place the discussions were over until now by the way.

> No spec is perfect, nor should we waste
You do but recognise at least that what was merely a question from my 
part showed that a few people hanging around here agreed on the 
misleading name and a good alternative was quickly found. You have the 
right to dismiss of course.
> and when it's actually submitted for consideration as a standards track
Well I wonder how since you define what's important and what's not.

I'm a bit annoyed now because my first message was not aiming at 
changing the draft but to understand the meaning of that choice but now 
you simply disregard any point of view at least me could make based on 
the fact it is implemented through various vendors.
This is all fine as it's your decision but the way you put things is a 
bit difficult to accept from a regular user point of view like me.

Could you please state on your blog then that the call for discussion on 
this draft is over so that things become clear?

- Sylvain

---

From: James M Snell <[email-masked]>
Date: Fri, 24 Mar 2006 12:18:20 -0800

> said in the first place the discussions were over until now by the way.

Not a problem :-) I had announced an informal "last-call" back around
the December 2005 timeframe.  But that was more or less designed to get
folks to actually read the spec than it was to lock things down. The
discussions are definitely not over but I want to avoid making generally
cosmetic changes because there are always going to be some folks who
aren't going to be happy.

> right to dismiss of course.

I also agree that the name change would be good and I seriously
considered making the change.  If I hear from enough implementors that
say changing it would not be a problem, I'd likely go ahead and do so.
(e.g. when I say "final" I usually mean "more than likely final but I'm
always open to be convinced otherwise" ;-) ..)

> Well I wonder how since you define what's important and what's not.

Please don't misinterpret, I'm not disregarding any point of view on
this.  I've seriously considered every bit of feedback offered and
greatly appreciate it.. and, like I said above, it's always possible to
convince me to make a change if there's enough support for it.

So, with that, let me go ahead and open it up to a vote with the caveat
that votes from folks with concrete plans to implement the spec will
carry more weight so I'd appreciate a heads up.

1. Do I change <in-reply-to id="..." /> to <in-reply-to ref="..." /> ?

and.. to address David's concerns about extending atom:link...

2. Do I change thr:count and thr:when to extension elements instead of
attributes on atom:link?

None of the implementors I'm aware of are currently making use of
multiple replies link relations on an entry so changing #2 likely
wouldn't cause too many headaches.

My apologies if I came across a little too heavy handed on this. That
was most definitely *not* the intention.

- James

---

From: James M Snell <[email-masked]>
Date: Fri, 24 Mar 2006 12:31:42 -0800

Oh, and I forgot to say that the folks who have already commented in
favor of the id-to-ref rename already have their votes counted ;-)

And yes, Dave, I'm counting your comments regarding #2 as a +1..

- James

---

From: "James Holderness" <[email-masked]>
Date: Sat, 25 Mar 2006 06:38:55 +0200

> 1. Do I change <in-reply-to id="..." /> to <in-reply-to ref="..." /> ?

I don't know enough to care what you call those attributes. And it's a long 
way before we'll go live with anything so if you need to change attribute 
names it wouldn't bother me in the least.

> 2. Do I change thr:count and thr:when to extension elements instead of

I currently have no interest in supporting either of those so it doesn't 
matter to me.

Regards
James

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Sat, 25 Mar 2006 14:39:02 +0100

Hello James,

+1
> 2. Do I change thr:count and thr:when to extension elements instead of
+1 although I'm less annoyed by this one if you keep it as it is now.
> was most definitely *not* the intention.
Thank you very much for the feedback then as I was getting afraid we 
would not be able to simply discuss around here :D
So thank you.

- Sylvain

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sat, 25 Mar 2006 16:33:43 +0100

>1. Do I change <in-reply-to id="..." /> to <in-reply-to ref="..." /> ?

+1, in case my implicit vote isn’t already counted.

>2. Do I change thr:count and thr:when to extension elements
>instead of attributes on atom:link?

+0; but I don’t plan on using those on either end of the wire.

Regards,

---

From: "Thomas Broyer" <[email-masked]>
Date: Mon, 27 Mar 2006 09:12:32 +0200

> 1. Do I change <in-reply-to id="..." /> to <in-reply-to ref="..." /> ?

+0.5, I have no real problem with id but as it seems to bother some people…

+1

> wouldn't cause too many headaches.

I wouldn't understand what really does mean the following:
<link rel="replies" href="comments.html" type="text/html" thr:count="5" />
<link rel="replies" href="comments.atom" type="application/atom+xml"
thr:count="10" />
Without the thr:count, I'd say that those two links are intended for
client-side content negotiation, but given that the two thr:count
values differ… would it mean that there have been 5 new comments since
the text/html representation has been last updated? But what if there
were a thr:when indicating the opposite?

And Rob Sayre also pointed on his blog a potential problem on how to
use such multiple values: "How do I display that in a client? Do I add
up the numbers? Pick the highest? Do I pick the latest or the earliest
time?". [http://www.franklinmint.fm/blog/archives/000721.html]
I know what your answer is [http://www.snellspace.com/wp/?p=297] but I
also think that these are entry properties, not really link properties
(so I disagree with you on "First, The thr:count and thr:when
properties are specific to the replies link upon which they appear."
[http://www.snellspace.com/wp/?p=296]).

--
Thomas Broyer

---

From: James M Snell <[email-masked]>
Date: Mon, 27 Mar 2006 01:51:43 -0800

The key confusion point around how to process thr:count and thr:when is
simple: there is no processing model for them.  They're strictly
advisory. They're nothing more than a hint about how many replies may be
found at the link specified, or when the most recent reply may have been
placed.  If there is a mismatch between those values and reality,
reality wins.  There is no spoon.

> were a thr:when indicating the opposite?

The difference in numbers between each link thr:count does not imply any
meaning beyond: "There may be 10 replies found in the atom feed, and
there may be 5 replies found in the html page"... such would make sense,
for example, if the html page was set up only to show the five most
recent entries/replies while the atom feed is set up to show the ten
most recent entries/replies.  The point being, you cannot compare the
two numbers from the two links and expect to derive any meaning from the
comparison, particularly given that Atom does not define any particular
relationship among link elements of the same type (e.g. two "related"
links are not necessarily content-negotiated alternatives of one another).

> [http://www.snellspace.com/wp/?p=296]).

No, the semantic of thr:count is not "How many total replies does this
entry have".  The semantic of thr:count is "How many replies may be
found at this linked location".  It's a shortcut.  Feed publishers who
know how many replies have been made can include it in their replies
link so clients don't have to pull the feed, parse it out, and count the
number of entries in in-reply-to links just to show a "Comments (5)"
link/label in their UI.

- James

---

From: Andreas Sewe <[email-masked]>
Date: Mon, 27 Mar 2006 18:03:54 +0200

James M Snell wrote:
> So, with that, let me go ahead and open it up to a vote with the
> caveat that votes from folks with concrete plans to implement the
> spec will carry more weight so I'd appreciate a heads up.
> 
> 1. Do I change <in-reply-to id="..." /> to <in-reply-to ref="..." />?

+1. (Just for the record and in case I haven't made it on James' yet)

> 2. Do I change thr:count and thr:when to extension elements instead
>    of attributes on atom:link?

-0. Given that the whole s/id/ref/ discussion was only about a cosmetic
change and that David's <ex:linkinfo> workaround syntax is plain ugly, I
would rather see Atom Extension Attributes standardized, then having to
resort to something like <ex:linkinfo>. If only atom:link were extensible...

Regards,

Andreas Sewe

---

From: James M Snell <[email-masked]>
Date: Wed, 29 Mar 2006 12:57:45 -0800

Given the response to this, in-reply-to/@id will be renamed to
in-reply-to/@ref.  thr:count and thr:when will remain as currently defined.

- James

James Holderness wrote:
> I don't know enough to care what you call those attributes. And it's a
> long way before we'll go live with anything so if you need to change
> attribute names it wouldn't bother me in the least.
>