Subject: Comments Draft

From: James M Snell <[email-masked]>
Date: Thu, 28 Jul 2005 16:58:19 -0700

Here is the draft. I have NOT yet submitted it for publication.  I am 
offering it here for review purposes.  Please take a look and send me 
your comments.

http://www.snellspace.com/public/draft-snell-atompub-feed-thread-00.txt

Major change: I've renamed the various link rel values:

  * "in-reply-to" is unchanged
  * "comments" is now called "replies" to align better with 
"in-reply-to"  (e.g. not all "replies" can be considered "comments")
  * "root" is now called "replies-source"... which is a horrible name 
but I'm not sure what else to call it

I'm going with the IANA registration route with these rather than the 
fully qualified URI.

- James

---

From: Antone Roundy <[email-masked]>
Date: Thu, 28 Jul 2005 18:24:58 -0600

> but I'm not sure what else to call it
How about "start-of-thread".

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 29 Jul 2005 22:41:53 +0200

* Antone Roundy <[email-masked]> [2005-07-29 02:40]:
> > "root" is now called "replies-source"... which is a horrible
> > name but I'm not sure what else to call it
> >

Or maybe “parent-entries?”

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

---

From: James M Snell <[email-masked]>
Date: Fri, 29 Jul 2005 16:28:31 -0700

Right. Nor is there any guarantee that the referenced entity will 
actually contain the original entry... e.g. it's possible that it could 
point to a feed that has been updated such that the original entry has 
already moved off of it.  It's really just a hint as to where original 
entries MIGHT be found. 

Antone Roundy wrote:

>
> On Friday, July 29, 2005, at 02:41  PM, A. Pagaltzis wrote:
>
> How about "mother-of-all-entries"?  Ha ha.
>
> The problem with "parent-entries" is that this link may not be 
> pointing to the immediate parent, right?
>
>

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sat, 30 Jul 2005 02:38:35 +0200

* James M Snell <[email-masked]> [2005-07-30 01:40]:
> It's really just a hint as to where original entries MIGHT be
> found. 

“originally-at?”

Regards,

---

From: Antone Roundy <[email-masked]>
Date: Fri, 29 Jul 2005 16:31:45 -0600

The problem with "parent-entries" is that this link may not be pointing 
to the immediate parent, right?

---

From: Graham <[email-masked]>
Date: Sat, 30 Jul 2005 16:37:18 +0100

>> It's really just a hint as to where original entries MIGHT be

source?

Graham

---

From: James M Snell <[email-masked]>
Date: Sat, 30 Jul 2005 08:58:21 -0700

Yeah, source is likely the most logical choice, but I didn't want to 
confuse folks with a link @rel="source" that has a different meaning 
from atom:source.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sat, 30 Jul 2005 22:38:55 +0200

* James M Snell <[email-masked]> [2005-07-30 18:10]:
> Yeah, source is likely the most logical choice, but I didn't
> want to confuse folks with a link @rel="source" that has a
> different meaning from atom:source.

An argument by way of which I came around to Antone’s suggested
“start-of-thread,” though I was going to suggest “thread-start.”

But then I thought, we already use mail header lingo with
“in-reply-to;” why not borrow another term from there and call it
“references?” Yes, I know it’s not the same as the References:
header. But the ultimate purpose (to trace the thread in
newsreaders) is kind of similar, and more importantly, the term
seems to fit the sort of relationship we’re trying to describe
quite closely.

If this is deemed a poor choice, then I fall back to
“thread-start.”

Regards,

---

From: Antone Roundy <[email-masked]>
Date: Sat, 30 Jul 2005 14:55:33 -0600

> “start-of-thread,” though I was going to suggest “thread-start.”
I took a look at the draft to verify whether I correctly understood 
what this link points to, and I think it isn't what I originally 
thought based on the old name "root".  Does this point to the feed in 
which the immediate parent entry was found, or to the feed in which the 
first entry in a thread of replies was found?  If the former, which the 
draft seems to suggest, and which seems more useful, then 
"start-of-thread" and "thread-start" probably aren't such good names 
after all.  With clarity in mind, "in-reply-to-feed" might be good, 
though it's a bit long.

And problem comes to mind: if you have multiple "in-reply-to" links, 
how do you related those to their respective "in-reply-to-feed" links 
(in case they're different)?  Is it possible?  Dare we do something 
like this?  (Wish we to if we dare?)

<link rel="in-reply-to" ...>
	<link rel="in-reply-to-feed" ... />
</link>

Pro:
* Groups the two links together
* Gives us more options for what to call the inside one without 
creating confusion: "source-feed", for example.  It would be nice to 
choose a name that's not likely to be the perfect name for some other 
use, or to define this @rel value broadly enough to be applicable to 
other purposes.

Con:
* Puts an atom:link in a location not expected by apps that don't 
understand this extension.

---

From: Justin Fletcher <[email-masked]>
Date: Sat, 30 Jul 2005 22:15:48 +0100 (BST)

> seems to fit the sort of relationship we’re trying to describe

The 'In-Reply-To' in mail terms supplies the unique identifier used to
identify the previous message. In this respect the comments draft matches
up quite nicely. However, 'References' is the set of referenced messages
in the source document, plus the unique identifier of the source document.
It makes sense to not reuse the mail term differently when there is
already a parallel drawn with the 'in-reply-to'.

> If this is deemed a poor choice, then I fall back to

I'm not sure that 'start' is suitable here, because the source document
referenced may not be the start of the discussions - it only refers to the
parent to which the response pertains.

I'm quite happy with 'replies-source' because it does not indComparing to mail seems to be a reasonable thing to do - mail has a
considerable amount of prior implementation and understanding from which
concepts can be drawn. However, there is no equivilent in mail terms for
the purpose of the 'replies-source'.

If I were to question the 'replies-source' name at all, I'd say that it
should be 'reply-source' because the entry refers to only a single reply
and not to multiple replies. This also brings it in line with
'in-reply-to'.

-- 
Gerph <http://gerph.org/>
... Never did find my way home in time to forgive her.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sat, 30 Jul 2005 23:47:14 +0200

* Justin Fletcher <[email-masked]> [2005-07-30 23:25]:
> I'm quite happy with 'replies-source' because it does not
> indComparing to mail seems to be a reasonable thing to do -
> mail has a considerable amount of prior implementation and
> understanding from which concepts can be drawn. However, there
> is no equivilent in mail terms for the purpose of the
> 'replies-source'.

I’m -1 on using “replies-source”; I should have said so more
explicitly before. To me it is non-sensical, as it parses as “the
source of replies,” which is the opposite relationship of what
it’s supposed to express. It’s not where the replies come from,
it’s where the entries being replied to come from.

I suppose the criticism on “thread-start” and “references” is
valid… but I still think that “references” is linguistically the
closest to what we are trying to express.

Maybe “references-source?”

Regards,

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sat, 30 Jul 2005 23:59:43 +0200

* Antone Roundy <[email-masked]> [2005-07-30 23:05]:
> creating confusion: "source-feed", for example.  It would be
> nice to choose a name that's not likely to be the perfect name
> for some other use, or to define this @rel value broadly enough
> to be applicable to other purposes.
> 
> Con:
> * Puts an atom:link in a location not expected by apps that
> don't understand this extension.

I like it.

I’d prefer to eliminate the one contra you listed by using an
extension element for this purpose (as always, nested into the
link.) Of course, that means need a namespace…

It’s a good solution to the bikeshed of naming the relationship,
and it keeps the information about the entry being replied to and
its source coupled together. With a plain old @rel value, you
can’t tell which ones belong together in an entry with several
links of both kinds.

So far I can’t really make up my mind on any one solution, but
this one seems the most correct, all else considered.

Regards,

---

From: Antone Roundy <[email-masked]>
Date: Sat, 30 Jul 2005 16:16:26 -0600

> link.) Of course, that means need a namespace…

Given that the link to the feed is traversable, and the "link" to the 
ID of the entry may not be, I'd suggest using an extension element for 
the possibly-non-traversable link, if for either....which would leave 
us needing to pick a good @rel value for the traversable one.  That 
would also keep my con point around:

<foo:non-traversable-reference id-of-other-entry="...">
	<link ... />
</foo:non-traversable-reference>

...unless it were done this way:

<link ...>
	<foo:non-traversable-reference id-of-other-entry="..." />
</link>

...but doesn't quite work, because the logical relationships between 
the elements are entry to foo:non-traversable and foo:non-traversable 
to link, not entry to link and link to foo:non-traversable.

I'm satisfied to live with the negative point of having a link in an 
unexpected place.  And since I don't like non-traversable atom:links, I 
myself prefer <foo:non-traversable><link/></foo:non-traversable>, 
though I don't expect it to be adopted.

---

From: James M Snell <[email-masked]>
Date: Sat, 30 Jul 2005 15:18:12 -0700

I agree. I'd much rather avoid introducing a new namespace for this 
tho.  Nested link elements if just fine I think

<link rel="in-reply-to" href="...">
   <link rel="source" href="..." />
</link>

Using source in this context I think avoids the potential confusion had 
the link appeared without nesting. 

The fact that it solves the problem of associating a single in-reply-to 
to a single source location is an added bonus.

Definitely works for me.

---

From: James M Snell <[email-masked]>
Date: Sat, 30 Jul 2005 15:37:15 -0700

One challenge is that for anything besides references to Atom entries, 
there is no guarantee that in-reply-to links will be non-traversable.  
For instance, if someone were to go and define a behavior for using 
in-reply-to with RSS, the href of the link may point to the same URL 
that the RSS item's link element points to (given that there is no way 
to uniquely identify an RSS item). 

<link rel="in-reply-to" type="text/html" 
href="http://www.example.com/entries/1" />

This is legal in the spec but is left undefined.

- James

Antone Roundy wrote:

> unexpected place.  And since I don't like non-traversable atom:links, 
> I myself prefer <foo:non-traversable><link/></foo:non-traversable>,

---

From: Antone Roundy <[email-masked]>
Date: Sat, 30 Jul 2005 17:04:53 -0600

> This is legal in the spec but is left undefined.

The natural choice of values when replying to an RSS 2.x item would be 
the guid, since it's the closest counterpart to atom:id.  But if the 
guid is not a permalink (ie. not dereferencable), then it won't have a 
MIME type, just as non-dereferencable atom:id's don't have a MIME type. 
  Both of these facts suggest that the following sentence should 
probably be removed from section 3:

    If the type attribute is omitted, it's value is assumed to be 
"application/atom+xml".

Instead, I'd suggest stating that if the type attribute is omitted, the 
in-reply-to link cannot be assumed to be dereferencable, and that 
non-dereferencable links MUST NOT have a type attribute.

Editorial notes about this sentence:

    A type attribute
    value of "application/atom+xml" indicates that the resource being
    responded to is an atom:entry and that the href attribute MUST
    specify the value of the parent entries atom:id element.

1) "parent" probably isn't the best word here since in-reply-to isn't 
being defined in terms of parents and children.

2) "entries" -> "entry's"

I could add more, but instead, here's my suggestion for replacing that 
sentence:

If the resource being replied to is an atom:entry, the value of the 
href attribute MUST be the atom:id of the atom:entry.  If the value of 
the type attribute is "application/atom+xml" then the href attribute 
MUST be the (URL/URI/IRI) of an Atom Entry Document containing the 
atom:entry being replied to.

Anything else could lead to inconsistencies.  For example, when 
replying to an atom:entry that can be found in an Atom Entry Document, 
but whose atom:id does NOT point to that document, there would be 
multiple choices available for the reply link's href attribute.

---

From: David Powell <[email-masked]>
Date: Sun, 31 Jul 2005 01:09:44 +0100

>         <link rel="in-reply-to-feed" ... />

I'm not at all keen on extending the link element in this way. Atom
Publishing Servers that don't know about this extension that receive
an entry containing nested links from a publishing client will most
likely drop the content of the link and publish it to clients without
the inner link.

I don't believe that atom:link isn't usefully extensible other than by
creating new @rel values; or if you want something more powerful, use
extension elements.

Atom's extensibility framework has been touted as one of Atom's major
advantages[1] over RSS. Nested link elements sound a bit too much like
[2], but without the namespaces constraint.

[1] http://www.intertwingly.net/wiki/pie/Rss20AndAtom10Compared#x
[2] http://blogs.law.harvard.edu/tech/rss#extendingRss

-- 
Dave

---

From: David Powell <[email-masked]>
Date: Sun, 31 Jul 2005 01:14:29 +0100

Sunday, July 31, 2005, 1:09:44 AM, I wrote:

> I don't believe that atom:link _isn't_ usefully extensible other than by

er, that should be "is"

-- 
Dave

---

From: Eric Scheid <[email-masked]>
Date: Sun, 31 Jul 2005 10:39:05 +1000

On 31/7/05 7:47 AM, "A. Pagaltzis" <[email-masked]> wrote:

> I¹m -1 on using ³replies-source²; I should have said so more
> explicitly before. To me it is non-sensical, as it parses as ³the
> source of replies,² which is the opposite relationship of what
> it¹s supposed to express. It¹s not where the replies come from,
> it¹s where the entries being replied to come from.

"original-replies-target"?

e.

---

From: Eric Scheid <[email-masked]>
Date: Sun, 31 Jul 2005 12:32:39 +1000

>     <foo:non-traversable-reference id-of-other-entry="..." />

Why not this...

    <link href="derefence-URI" foo:idref="id-of-other-entry" />

--------------------------------

While true that nesting elements does allow for more flexible cardinality,
in practice will that actually happen? That is, how likely is this?

Similarly, does this make any sense at all?

    <link ...>

I can't see how. I've we're going limit the number of sub-elements to
zero-or-one, then we can just stick that into an attribute of the parent
element.

e.

---

From: Justin Fletcher <[email-masked]>
Date: Sun, 31 Jul 2005 03:44:10 +0100 (BST)

> it’s where the entries being replied to come from.

Hmm. I see what you mean.

> Maybe “references-source?”

From what I've seen of comments it is the terms which are used which are
causing problems. This may be partly because of the confusion over the
use to which the words are being put - 'replies' is already specified as
being the place where the responses to this reply will appear.
'references' implies that there are plural preceding resources being
referred to when there is only a single resource referenced. 'start'
implies the top of a heirarchy, when actually it could be anywhere within
that heirarchy to which this resource is a response.

Might it make sense to refer to the documents explicitly using the terms
'parent' and 'child' ? Whilst the mail terminology makes sense, I would be
pretty sure that people would understand the family-relationship this
invokes.

Current draft term   Familial term

replies-source       parent
in-reply-to          parent-id
replies              children

This would result in links such as ...

  <link rel="parent" type="application/atom+xml"
        href="http://other.example.com/"/>
  <link rel="parent-id" type="application/atom+xml"
        href="tag:other.example.com:23"/>
  <link rel="children" type="application/atom+xml"
        href="http://here.example.com/stuff.atom"/>

or, as a non-Atom-specific example ..

  <link rel="parent" type="message/rfc822"
        href="news:alt.foo"/>
  <link rel="parent-id" type="message/rfc822"
        href="news:[email-masked]"/>

It could be argued that 'parent' and 'child' should really be
'parent-document' and 'child-document'. However, it can be seen from the
above that 'news:alt.foo' doesn't actually refer to a document, but merely
to the method of locating the identifier referenced by the 'parent-id'
relation.

Does that make any more sense than the three names we already have ? Or is
the problem I see only in my own head ?

-- 
Gerph <http://gerph.org/>
... It's never sure, it's never pure, it always hurts.

---

From: Eric Scheid <[email-masked]>
Date: Sun, 31 Jul 2005 14:02:50 +1000

> it¹s where the entries being replied to come from.

replies-referent then? (ie. the target of a reference)

e.

---

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

* David Powell <[email-masked]> [2005-07-31 02:20]:
> I'm not at all keen on extending the link element in this way.
> Atom Publishing Servers that don't know about this extension
> that receive an entry containing nested links from a publishing
> client will most likely drop the content of the link and
> publish it to clients without the inner link.

Strictly speaking, per Extensions To the Atom Vocabulary (sec.
6.2), an Atom processor must treat the nested link as it would
treat any other Structured Extension Element (sec. 6.4.2).

However, sec. 6.2 implies that such elements which have the
characteristics of an Extension Element but come from the Atom
namespace can only be introduced by future versions of Atom and
both sec. 6.4.1 and sec. 6.4.2 seem to explicitly forbid elements
from the Atom namespace (although that might only be what my RNC
analphabeticism suggests).

So Atom processors would have to treat this markup “correctly.”
The spec does not allow us to extend Atom in this way, however,
and that makes sense, too: what if a future version of Atom were
to allow nested links, but with semantics that differ from those
in this threading extension? This is exactly the situation that
the definitions in Extending Atom (sec. 6) seek to prevent.

Regards,

---

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

* James M Snell <[email-masked]> [2005-07-31 00:30]:
> I agree. I'd much rather avoid introducing a new namespace for
> this tho.  Nested link elements if just fine I think
> 

Nope. As I just wrote in reply to David Powell, sec. 6 of the
spec forbids this, and rightly so. It reserves use of elements
from the Atom namespace in places other than those specified for
use by future versions of the Atom spec *only* for good reason.
What if a future version of Atom were to specify nested links,
but with semantics that differ from the threading extension?
Suddenly, all existing Atom documents with threading clash with
the spec.

It’s either a regular non-nested link element with a new @rel
value or an extension element with a new namespace.

Regards,

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sun, 31 Jul 2005 18:24:00 +0200

* Antone Roundy <[email-masked]> [2005-07-31 01:15]:
> I could add more, but instead, here's my suggestion for
> replacing that sentence:
> 
>     If the resource being replied to is an atom:entry, the
>     value of the href attribute MUST be the atom:id of the
>     atom:entry. If the value of the type attribute is
>     "application/atom+xml" then the href attribute MUST be the
>     (URL/URI/IRI) of an Atom Entry Document containing the

This undermines the purpose of the link. Atom Entry Documents can
move around; their IDs are eternal.

Regards,

---

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

* Antone Roundy <[email-masked]> [2005-07-31 00:30]:
> I'm satisfied to live with the negative point of having a link
> in an unexpected place.

Except the spec forbids it. Only future versions of the Atom spec
may define elements from the Atom namespace in locations that
other than those currently specified. Read sec. 6 of the spec,
particularly the implications of sec. 6.2. See also sec. 6.4.1
and .2 for how Extension Elements must not be in the Atom
namespace.

Regards,

---

From: David Powell <[email-masked]>
Date: Sun, 31 Jul 2005 20:34:31 +0100

> treat any other Structured Extension Element (sec. 6.4.2).

Only child elements of atom:entry, atom:feed, and person constructs
(and pending bugfixes: atom:source) can be Structured Extension
Elements (Metadata Elements). Child elements of atom:link are not
Metadata Elements, and neither are foreign-namespaced attributes; they
are undefined markup.

It might be possible to get away with using undefined markup to
communicate between two consenting parties, but I don't think that it
forms a viable platform for extension. It falls outside of the Atom
model, and it can only be preserved between publishing client,
publishing server, feed publication, and aggregator if all parties
either have special case support for the extension, or they preserve
the document's entire Infoset intact along every step in the chain. I
don't believe that the latter is a realistic expectation for Atom
implementations, so it seems reasonable behaviour for a publishing
server to just drop undefined content, such as foreign-namespaced
attributes and atom:link children, and to just publish the link
without them.

Personally, I read "undefined" more like how C uses the word
undefined.

-- 
Dave