Subject: On LinkTagMeaning...

From: Norman Walsh <[email-masked]>
Date: Sat, 17 Jul 2004 17:32:40 -0400

My initial impression of all those @rel values is to run screaming.
We're designing an XML format, we have a widely deployed,
well-established extensibility mechanism at our fingertips, why aren't
we using it? I know why HTML didn't use it, but we don't have the same
constraints.

In the -00 draft, we have seven @rel values:

   attribute rel {
      "alternate"
    | "start"
    | "next"
    | "prev"
    | "service.edit"
    | "service.post"
    | "service.feed" },

It seems to me that those fall neatly into three categories: alternate
formats, threading, and Atom protocol services.

Looking at LinkTagMeaning I see (very broadly) three more categories:
comments, processing, and icons.

My two cents:

1. We need alternate formats, let's have a tag for that.

2. We'll never get consensus on threading, let's not try. Let the
   folks who are interested develop a few extension vocabularies for
   it, let's take them around the block a few times, kick the tires,
   see what we like and standardize something in 18 months.

3. We need protocol services, let's have a tag for that.

4. Let's lump coments in with threading and let a thousand flowers
   bloom.

5. We'll never get consensus on a processing model that allows Atom
   feeds to be transformed arbitrarily by producers and consumers at
   arbitray points in the life cycle of an entry. It just ain't going
   to happen. Let the folks who are interested develop a few extension
   vocabularies for it, let's take them around the block a few times,
   kick the tires, see what we like and standardize something in 36
   months (or 120 maybe).

6. I think feed producers would like the ability to associate an image
   with their feeds, maybe an icon and another larger image. Let's
   have a tag for that.

I have a hard time imagining any real value that would come from being
able to tell that a random extension element contains a link. Here:

   <ndw:whizbang @rel="tatters" href="http://example.org/ralphie"/>

Good luck doing anything useful with that. Given the diversity of link
relationships that we're considering, it wouldn't even make a lot of
sense to put that up as a link for the reader to click on.

There will be extension vocabularies. Some of them will include links.
Some of them will be popular. Some of them will gain critical mass. Some
of them will be supported by tools. Some of them will only ever be used
by four random friends. That's ok.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | It is good to have an end to journey
http://nwalsh.com/            | toward; but it is the journey that
                              | matters, in the end.--Ursula K. LeGuin

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Sun, 18 Jul 2004 00:30:52 +0200

> formats, threading, and Atom protocol services.

Small note, unless you read something different into threading than me,  
"start", "next" and "prev" does not describe threading.  They do, however  
describe relationships between atom entries.

>    see what we like and standardize something in 18 months.

I believe leaving this issue, just because "getting consensus" is hard, is  
a mistake. My suggestion would be to revisit one  of the approaches that  
have been mentioned, either here or in #atom - sum up, and decide on one  
model (possibly even a subset of these models).

If we put this into an extension vocabulary, I'm afraid threading, or any  
other relation mechanisms, such as supersedes/replaces or even  
prev/next/start are going to be plagued by competing mechanisms.

-- 
Arve Bersvendsen

http://www.virtuelvis.com
http://www.bersvendsen.com

---

From: Tim Bray <[email-masked]>
Date: Sat, 17 Jul 2004 15:53:58 -0700

On Jul 17, 2004, at 3:30 PM, Arve Bersvendsen wrote:

> Small note, unless you read something different into threading than 
> me, "start", "next" and "prev" does not describe threading.  They do, 
> however describe relationships between atom entries.

The distinction between this and threading is so fuzzy as to be not 
separable.

> I believe leaving this issue, just because "getting consensus" is 
> hard, is a mistake. My suggestion would be to revisit one  of the 
> approaches that have been mentioned, either here or in #atom - sum up, 
> and decide on one model (possibly even a subset of these models).

On the contrary.  There is no body of practice that proves we know how 
to solve the problem, and this group should not be in the business of 
speculative invention of new technologies.

> If we put this into an extension vocabulary, I'm afraid threading, or 
> any other relation mechanisms, such as supersedes/replaces or even 

This is good, because the problem is very far from being solved, and 
thus we need competing candidates if we're going to make progress. -Tim

---

From: Robert Sayre <[email-masked]>
Date: Sat, 17 Jul 2004 20:01:46 -0400

On 7/17/04 6:53 PM, "Tim Bray" <[email-masked]> wrote:

> thus we need competing candidates if we're going to make progress.

Unfortunately, prev/next/start are currently cornerstones of the protocol.
This is _not obvious_ [1] from the current draft. It's a problem we do have
to partially solve, I think. A Link Construct may not be the best way to do
it, however.

Robert Sayre

[1] 
http://www.ilrt.bris.ac.uk/discovery/chatlogs/atom/2004-06-29.html#T02-57-50

---

From: Tim Bray <[email-masked]>
Date: Sat, 17 Jul 2004 17:44:12 -0700

> to partially solve, I think. A Link Construct may not be the best way 

I didn't know that, and didn't find the IRC log to be very transparent. 
  Perhaps someone could enlarge on next/prev being "cornerstones of the 
protocol"? -Tim

---

From: Robert Sayre <[email-masked]>
Date: Sat, 17 Jul 2004 21:00:44 -0400

> Perhaps someone could enlarge on next/prev being "cornerstones of the

Let me try again. The smell of dinner encouraged me to make that email very
brief.

Check this out for an implementation of the FeedURI:
http://www.xml.com/pub/a/2004/04/14/atomwiki.html?page=2

Basically, the FeedURI[2] is similar in appearance to the main feed of a
site. The difference would be that it's expected to be a dynamic resource.
It uses next/prev to send paging parameters (most likely to itself). As the
editor's note says:

"the [FeedURI representation also] replaces the search facet by having
'link' tags that point to other feeds using  well knows 'rel' attribute
values such as 'next' and 'prev' "

I'm not so hot on paging as a discovery mechanism for editing clients, but
it is one approach.

Robert Sayre

[1] 

[2] 
http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-00.html#Feed
URI

---

From: Joe Gregorio <[email-masked]>
Date: Sat, 17 Jul 2004 21:23:29 -0400

>   Perhaps someone could enlarge on next/prev being "cornerstones of the

Each entry has an EditURI used for editing. GET on this
URI to fetch it, PUT an entry back to update it. 
The question is, how do you find out the EditURI of
the entry you want to edit in the first place?

The solution, as it stands today, is to use the FeedURI
which contains a list of N recent entries and in 
each entry is a pointer to the EditURI. Now this works
fine if you want to edit a recent entry, but what if you wanted
to go back further in time? That is what the 'prev' and 'next'
links are for, follow the 'next' URI and you get another atom
feed, in the same format as the FeedURI, but populated with
the next batch of N entries. It also contains yet another
'next' link.  You keep following 'next' links back in time 
until you get to the entry you want to edit. 

In the chatlog I make reference to a [2]
which is something that was a part of RESTLog,
and despite the poor usage of the term 'archive',
I would like to see brought into the Atom Publishing
Protocol. 

The problem with the 'next' and 'prev' links
is that the navigation is only linear. The format
I talk about in [2] allows for a more richly structured
browing of the archives where the depth and complexity
of the types of navigation is determined by the 
server.

A more detailed explaination of the 'next' and 
'prev' navigation as found in the -00 I-D is here[1]:

[1] http://webservices.xml.com/pub/a/ws/2004/02/03/atom8.html
[2] http://bitworking.org/news/Atom_Archive_Format

    Thanks,
    -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: Eric Scheid <[email-masked]>
Date: Sun, 18 Jul 2004 13:02:03 +1000

On 18/7/04 11:00 AM, "Robert Sayre" <[email-masked]> wrote:

> 'link' tags that point to other feeds using  well known 'rel' attribute

perhaps these should be "service.next" and "service.prev" then?

would "service.index" be another mechanism ... a single SSFF feed with
"service.edit" links?

e.

---

From: Dave Pawson <[email-masked]>
Date: Sun, 18 Jul 2004 09:00:02 +0100

> until you get to the entry you want to edit. 
<snip/>

> of the types of navigation is determined by the 

I can see the issue you are working at Joe, I'm less sure its 
open to a standard approach. For the chatty publisher the structure
could be long and deep. For the occasional publisher it could be
simply linear. Do you think it right that atom force you into
structuring your documents in a fixed way?
  Seems wrong to me.
The previous next idea meets the need, if somewhat laborious.

Can you propose something to improve on Norms idea without
introducing additional complexity?
  The edit approach seems to me like an application domain issue,
with the publishing side needing to support it, but I'd hope that
it won't start to constrain it too much.

Norms approach seems to capture the needs I've heard so far?

-- 
Regards DaveP.
XSLT&Docbook  FAQ
http://www.dpawson.co.uk/xsl

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Sun, 18 Jul 2004 12:22:45 +0200

> speculative invention of new technologies.

What about use of existing technologies?

Threading is a problem that has been discussed extensively elsewhere.

<URL: http://www.threadsml.org/ >
<URL: http://www.eyrie.org/~zednenem/2002/web-threads/tdl3.html >
<URL:  
http://dublincore.org/documents/2000/07/11/dcmes-qualifiers/#relation >

All of these resources would seem to cover most of what is needed from  
'threading' (sans some of the html @rel/@rev values).Dublin Core relation  
also seems to cover a simple revisioning mechanism

-- 
Arve Bersvendsen

---

From: Joe Gregorio <[email-masked]>
Date: Sun, 18 Jul 2004 07:47:47 -0400

> structuring your documents in a fixed way?

Not quite sure what you mean by that. If publishers
only want to support a 'prev-next' type of navigation
they can do that in my proposal. Here is some more 
detail on how the format can be used:

http://www.imc.org/atom-syntax/mail-archive/msg00763.html

> introducing additional complexity?

Norm is only proposing changes in the names of
the elements/attributes, which is orthogonal
to what I am talking about here. If you go back
an re-read the thread you can see how we drifted. 

    Thanks,
    -joe

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 18 Jul 2004 09:22:44 -0700 (PDT)

> <URL: http://www.threadsml.org/ >
http://www.eyrie.org/~zednenem/2002/web-threads/tdl3.html
> <URL:  
http://dublincore.org/documents/2000/07/11/dcmes-qualifiers/#relation

I am unaware of any sites or aggregators that support
any of the aforementioned threading specs. Can anyone
point to any aggregators that support any of these
specs? Or point to more than one site that uses them? 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.

__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Sun, 18 Jul 2004 18:43:21 +0200

> specs? Or point to more than one site that uses them?

This is a chicken-and-egg problem: No feeds use these mechanisms because  
no aggregator supports them, and no aggregator supports them because no  
feeds use them.

There are however newsfeeds that would benefit from this. Examples that  
come to mind:

- Phil Ringnaldas blog does threaded comments;  
http://www.philringnalda.com/
- A threading plugin exists for Movable Type.  
http://mt-plugins.org/archives/entry/threadedcomments.php
- Postnuke/PHPNuke does threading. Probably a bunch of other CMSes as well.
- The new Google Groups 2 beta has atom feeds. See  
http://groups-beta.google.com/group/comp.lang.python/feeds for an example.

So, _people_ and _software_ do threading, but Atom has no way of  
expressing this.

-- 
Arve Bersvendsen

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 18 Jul 2004 10:01:33 -0700 (PDT)

> There are however newsfeeds that would benefit from

Any site that supports comments would benefit from the
ability to expose comments in their news feeds. 

> So, _people_ and _software_ do threading, but Atom

The threading mechanism I've seen in prominent use in
the wild is wfw:commentRss which is supported by a
handful of blogs (Sam Ruby's, Phil Ringnalda's) and
the major blogging tools written on ASP.NET (dasBlog &
RSS Bandit). Similarly the aggregators I've seen
supporting threading using this mechanism are the .NET
based ones (RSS Bandit & SharpReader as well as
Newzcrawler). Actually it seems Newzcrawler also
supports the blogcomments module. 

I don't see why Atom feeds can't use that extension or
any of the other 3 you mention. I don't think there's
much experience with implementing threading mechanisms
in the wild to start putting in the core Atom spec. 

=====

__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Sun, 18 Jul 2004 19:25:12 +0200

On Sun, 18 Jul 2004 10:01:33 -0700 (PDT), Dare Obasanjo <[email-masked]>  
wrote:

> the wild is wfw:commentRss

Looking around, I was only able to determine that wfw:commentRss is only a  
discovery/exposure mechanism for comments, and not a threading mechanism  
as such.

> in the wild to start putting in the core Atom spec.

Having threading in the core promotes usage.

Also: Don't forget that there is considerable experience with threading  
outside the feed/aggregator world. If you want a hands-on-tutorial on how  
to perform threading when in-reply-to and references is present, take a  
look at Jamie Zawinskis threading algorithm for Netscape 3, <URL:  
http://www.jwz.org/doc/threading.html >

-- 
Arve Bersvendsen

---

From: Ken MacLeod <[email-masked]>
Date: 18 Jul 2004 12:36:10 -0500

Dare Obasanjo <[email-masked]> writes:

> The threading mechanism I've seen in prominent use in the wild is
> wfw:commentRss which is supported by a handful of blogs (Sam Ruby's,
> Phil Ringnalda's) and the major blogging tools written on ASP.NET
> (dasBlog & RSS Bandit). Similarly the aggregators I've seen
> supporting threading using this mechanism are the .NET based ones
> (RSS Bandit & SharpReader as well as Newzcrawler). Actually it seems
> Newzcrawler also supports the blogcomments module.
> 
> I don't see why Atom feeds can't use that extension or any of the
> other 3 you mention. I don't think there's much experience with
> implementing threading mechanisms in the wild to start putting in
> the core Atom spec.

I think we're using different scopes for the word "threading".  Both
scopes are implemented exactly the same as in wfw:commentRss and in
Atom with the "service.feed" link on an atom:entry resource.

Current RSS threads are "flat".  The examples Arve linked to, and the
threading support being requested, are "nested".

The current proposal (PaceLinkParent) is for those entries in the
service.feed/wfw:commentRss feed to have a "parent" link to the entry
they reply to, so that clients that support that feature can show the
nesting level.  Clients that don't support that feature would properly
default to flat display.

Earlier you had suggested[1] that each nested comment should have its
own wfw:commentRss link, and Roger Benningfield described the "Yikes!"
scenario[2] with that approach.  This proposal keeps all the entries
in the same feed and also supports nested and flat comments.

  -- Ken

PS. My main objection to PaceLinkParent is that it is intentionally
overloading the term "parent".  I'll be creating a new proposal
shortly that is confined to just replies as used in the examples Arve
linked to.

[1] http://imc.org/atom-syntax/mail-archive/msg05611.html
[2] http://imc.org/atom-syntax/mail-archive/msg05639.html

---

From: Graham <[email-masked]>
Date: Sun, 18 Jul 2004 16:31:52 -0400

> by four random friends. That's ok.

+1 to that and to the suggested link replacements (though I thing 
prev/next or something equally simple might fit in v1.0). It's becoming 
more clear that not all link elements have the same requirements for 
attributes (eg image might need size attributes), so the value of a 
Link Construct at all is questionable.

(I'd also like to reiterate that the number of extension vocabularies 
that will re-use any kind of Link Construct is likely to be manageably 
small, and I don't expect it to be a big challenge for tool-vendors to 
be aware of all of the popular ones, so needing an automated way to 
find them seems unnecessary)

Graham

---

From: Norman Walsh <[email-masked]>
Date: Sun, 18 Jul 2004 18:10:14 -0400

/ Graham <[email-masked]> was heard to say:
| On 17 Jul 2004, at 5:32 pm, Norman Walsh wrote:
|> There will be extension vocabularies. Some of them will include
|> links. Some of them will be popular. Some of them will gain
|> critical mass. Some of them will be supported by tools. Some of
|> them will only ever be used by four random friends. That's ok.
|
| +1 to that and to the suggested link replacements (though I thing
| prev/next or something equally simple might fit in v1.0). It's

How would that be used? I've always imagined that sorting on one of
the date fields gives an effective linear order. Are there any tools
that use a prev/next link? How do they use it? What do they do with
entries that are 'skipped' in the feed?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Doubt is to certainty as neurosis is to
http://nwalsh.com/            | psychosis. The neurotic is in doubt and
                              | has fears about persons and things; the
                              | psychotic has convictions and makes
                              | claims about them. In short, the
                              | neurotic has problems, the psychotic
                              | has solutions.--Thomas Szasz

---

From: Graham <[email-masked]>
Date: Sun, 18 Jul 2004 22:18:09 -0400

> entries that are 'skipped' in the feed?

Are you talking about fir relationships between entries? That doesn't 
make much sense, no. I mean for feeds - ie The main feed has a previous 
(or next - no one's sure) link to a feed of the earlier n entries, 
which has a link to the n before that, etc. It's not very robust and 
you'd have to periodically look through the whole lot for changes, but 
still, it's a lot better than not being able to get at previous entries 
at all.

Graham

---

From: Norman Walsh <[email-masked]>
Date: Mon, 19 Jul 2004 08:15:05 -0400

/ Graham <[email-masked]> was heard to say:
| Are you talking about fir relationships between entries? That doesn't
| make much sense, no. I mean for feeds - ie The main feed has a
| previous (or next - no one's sure) link to a feed of the earlier n
| entries, which has a link to the n before that, etc. It's not very
| robust and you'd have to periodically look through the whole lot for
| changes, but still, it's a lot better than not being able to get at
| previous entries at all.

Ah. Ok. I wasn't thinking about that. I guess that could be useful,
though I chose a different solution myself: I make a feed of the "top
30" that rotates over time and a feed of "everything". (Actually, I
make a bunch of topic-specific feeds too.)

But I can imagine that the "everything" feed might eventually be so
large that it was impractical and I'd want to break it into pieces.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | We do not know what thoughts stirred in
http://nwalsh.com/            | the mind of the last of the mastodons,
                              | but we can take it that they were
                              | nothing very remarkable. It is hardly
                              | likely that the last man will have the
                              | mind of a Goethe. He will die, and that
                              | will be the last stage of human
                              | progress.--Anatole France