Subject: Thread/comment extension refactoring

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

Hi all,

okay, after the latest round of discussion, I think we need to
start over from scratch with what we’ve learned in the process so
far.

My chain of thought:

• atom:id is an opaque URI. It is permissible per the spec to put
  such a value in atom:link/@href, but that’s a “creative”
  reading which I suggested because it would avoid having to
  define an extension element.

  However, that was before James’ motion to preserve information
  about the feed where the entry being replied to appeared. Now
  we need a way to associate the atom:id and the feed source URL
  with each other.

• We may not stick atom:link anywhere besides directly inside an
  atom:feed or atom:entry, because of the implications of sec. 6,
  which preserves use of elements from the Atom namespace in
  unexpected locations for use by future versions of the Atom
  spec. This restriction is there for good reason: it means that
  documents which conform to the Atom spec now will conform to
  future versions of the Atom spec also; if we start putting Atom
  namespaced elements wherever we want on a whim of the moment,
  we destroy forward compatibility.

• This means that coupling the information about the atom:id of
  the entry being replied to and the source where that entry was
  found will *require* an extension element or attribute.

  Thus, the benefit of my suggestion to put the atom:id in an
  atom:link is nullified and the argument that it’s not
  necessarily a traversible URI gains enough weight that the
  proposition should be discarded.

• In light of these issues, an approach much like Eric’s
  suggestion seems like the only sensible approach:

      <link
          rel="via"
          href="{$original-entry/../atom:link[@self]/@href}"
          thr:in-reply-to="{$original-entry/atom:id}"
      />

  As you see, I suggest using the standard “via” relationship
  here. It seems that with all the information we have, it is not
  necessary to describe the relationship in any more specifity.

• Unfortunately, that creates a problem for replies where there’s
  no URL to identify the feed, such as feeds delivered via SMTP
  (or maybe via XMPP – not sure if something like a URL exists
  there). After all, @href is mandatory (it’s the only atom:link
  attribute which is, in fact).

  It seems inevitable to specify an extension element, then.

      <entry>
        <thr:in-reply-to><xsl:value-of select="$original-entry/atom:id}"></thr:in-repl-to>
        <!-- ... -->
      </entry>

  But having both an attribute and an element is unnecessarily
  complex; so where a source URL is available, that would then be

      <link rel="via" href="{$original-entry/../atom:link[@self]/@href}">
        <thr:in-reply-to><xsl:value-of select="$original-entry/atom:id}"></thr:in-repl-to>
      </link>

  Now this bothers me on the level that thr:in-reply-to is
  metadata about the entry, not about the link.

• Where do we go from here? A thr:in-reply-to element for the ID
  and a @rel='via' link for the source seem like the clearly most
  correct choices, but how do we correlate one with the other?

  Each entry being replied to is associated with exactly one
  source, while each source may supply multiple entries being
  replied to. An obvious approach is giving the atom:link an
  xml:id and defining @from on thr:in-reply-to.
  
  But that burdens the producer with the requirement of
  generating IDs unique within the feed document, and burdens the
  consumer with resolving the crossreferences.
  
  It also makes thr:in-reply-to a Structured Extension Element;
  without the attribute it could be a Simple one. The approach
  does have the advantage that you can refer to a feed-level
  atom:link from within an entry-level thr:in-reply-to, but I
  don’t know that that’s a particularly interesting benefit.

  One thing that occured to me is that all thread-aware
  processors will need to know what to with thr:in-reply-to. Not
  all of them will care about the link to the source. I don’t
  know if that’s of any consequence to anything, though.

• The funny thing about burdening the producer with generating
  unique IDs (if only within the document) is that he already has
  one: the atom:id being replied to!

  That thought leads me to:

      <thr:in-reply-to><xsl:value-of select="$original-entry-1/atom:id}"></thr:in-repl-to>
      <thr:in-reply-to><xsl:value-of select="$original-entry-2/atom:id}"></thr:in-repl-to>
      <link rel="via" href="{$original-entry/../atom:link[@self]/@href}">
        <thr:source-of><xsl:value-of select="$original-entry-1/atom:id}"></thr:source-of>
        <thr:source-of><xsl:value-of select="$original-entry-2/atom:id}"></thr:source-of>
      </link>

  The only complaint I can register against this approach is
  verbosity.

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

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sun, 31 Jul 2005 20:36:35 +0200

* A. Pagaltzis <[email-masked]> [2005-07-31 20:31]:
>   $original-entry/../atom:link[@self]/@href

That is, of course,

    $original-entry/../atom:link[@rel='self']/@href

Regards,