Subject: Atom Rank Extensions

From: James M Snell <[email-masked]>
Date: Mon, 01 May 2006 16:21:58 -0700

All,

A new draft of the Feed Rank extension has been published.  Andreas Sewe
has joined on as an author and has contributed significantly to this rev
of the draft.  There are many updates to the extension that are worth
highlighting.

http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-index-09.txt

First, the purpose of this extension is to provide a flexible means of
ranking entries within a feed.  For instance, a feed might represent an
ordered listing of items from a movie rental queue; or each entry in a
feed might contain a five star review ranking; or each entry in the feed
might represent a listing of a students graded homework assignment,
where each rank represents the grade assigned to the work, etc.

For example, when combined with Mark Nottingham's Feed History extension
for marking a feed as "complete", Feed Rank provides a good solution for
 representing a movie rental queue:

     <feed xmlns="http://www.w3.org/2005/Atom"
           xmlns:r="http://purl.org/syndication/rank/1.0">
       <id>tag:example.org,2006:my_movie_queue</id>
       <fh:complete xmlns:fh="http://purl.org/syndication/history/1.0"/>
       <title type="text">My Movie Queue</title>
       <updated>2006-05-01T12:00:00Z</updated>
       <author><name>James</name></author>
       <link rel="self" href="queue.xml" />
       <link href="queue.html" />
       <r:scheme name="tag:example.org,2006:my_movie_queue"
                 label="Queue Position"
                 significance="descending">
         <r:range minimum="0" step="1" />
       </r:scheme>
       <r:scheme name="tag:example.org,2006:movie_reviews"
                 label="Customer Reviews"
                 signifiance="ascending">
         <r:range minimum="0.0" maximum="5.0"
                  step="0.5" scale="1" />
       </r:scheme>
       <entry>
         <id>tag:example.org,2006:movies/chaplin/citylights</id>
         <title type="text">City Lights</title>
         <updated>2006-05-01T12:00:00Z</updated>
         <link href="/movies/chaplin/citylights.html" />
         <summary>Charlie Chaplin's cassic film</summary>
         <r:rank domain=""
           scheme="tag:example.org,2006:my_movie_queue">1</r:rank>
         <r:rank
           domain="tag:example.org,2006:movie_reviews"
           scheme="tag:example.org,2006:movie_reviews">4.5</r:rank>
       </entry>
       <entry>
         <id>tag:example.org,2006:movies/chaplin/moderntimes</id>
         <title type="text">Modern Times</title>
         <updated>2006-05-01T12:00:00Z</updated>
         <link href="/movies/chaplin/moderntimes.html" />
         <summary>Another Chaplin classic</summary>
         <r:rank domain=""
           scheme="tag:example.org,2006:my_movie_queue">3</r:rank>
         <r:rank
           domain="tag:example.org,2006:movie_reviews"
           scheme="tag:example.org,2006:movie_reviews">3.5</r:rank>
       </entry>
       <entry>
         <id>tag:example.org,2006:movies/chaplin/thegoldrush</id>
         <title type="text">The Gold Rush</title>
         <updated>2006-05-01T12:00:00Z</updated>
         <link href="/movies/chaplin/thegoldrush.html" />
         <summary>Chaplin in a frozen wilderness</summary>
         <r:rank domain=""
           scheme="tag:example.org,2006:my_movie_queue">2</r:rank>
         <r:rank
           domain="tag:example.org,2006:movie_reviews"
           scheme="tag:example.org,2006:movie_reviews">5.0</r:rank>
       </entry>
     </feed>

While there are a variety of changes throughout the entire spec, the key
differences in this draft lie in the definition of the Ranking Schemes.
 A Ranking Scheme is now defined as a set of discreet values and/or
ranges.

For instance, a typical U.S. grading scheme can be represented using a
series of ranges representing percentage values:

     <r:scheme name="tag:example.org,2006:grades"
               label="Percentage Grading System"
               significance="ascending">
       <r:range label="F"
                minimum="0.00"
                maximum="0.59"
                scale="2"
                step="0.01" />
       <r:range label="D"
                minimum="0.60"
                maximum="0.69"
                scale="2"
                step="0.01" />
       <r:range label="C"
                minimum="0.70"
                maximum="0.79"
                scale="2"
                step="0.01" />
       <r:range label="B"
                minimum="0.80"
                maximum="0.89"
                scale="2"
                step="0.01" />
       <r:range label="A"
                minimum="0.90"
                maximum="0.99"
                scale="2"
                step="0.01" />
       <r:value label="A+"
                scale="2">1.00</r:value>
     </r:scheme>

In contrast, the typical German grading scheme can be represented as a
set of discreet values:

     <r:scheme name="tag:example.org,2006:grades"
               label="Grading System"
               significance="descending">
       <r:value label="1"  scale="1">1.0</r:value>
       <r:value label="1-" scale="1">1.3</r:value>
       <r:value label="2+" scale="1">1.7</r:value>
       <r:value label="2"  scale="1">2.0</r:value>
       <r:value label="2-" scale="1">2.3</r:value>
       <r:value label="3+" scale="1">2.7</r:value>
       <r:value label="3"  scale="1">3.0</r:value>
       <r:value label="3-" scale="1">3.3</r:value>
       <r:value label="4+" scale="1">3.7</r:value>
       <r:value label="4"  scale="1">4.0</r:value>
       <r:value label="4-" scale="1">4.3</r:value>
       <r:value label="5+" scale="1">4.7</r:value>
       <r:value label="5"  scale="1">5.0</r:value>
       <r:value label="5-" scale="1">5.3</r:value>
       <r:value label="6+" scale="1">5.7</r:value>
       <r:value label="6"  scale="1">6.0</r:value>
     </r:scheme>

Anyway, as always, feedback is welcomed and requested.

- James

---

From: "Robert Sayre" <[email-masked]>
Date: Mon, 1 May 2006 21:39:15 -0400

On 5/1/06, James M Snell <[email-masked]> wrote:
>
> All,
>
> A new draft of the Feed Rank extension has been published.

I am uncomfortable with the numerous "standards track" documents
emanating from one person/company, especially when changes requested
by the community are met with hostility and channel flooding. An
excellent way to handle this gripe is to hold a BoF and let an Area
Director guage interest in a charter with defined goals.

When I read terms like "more standard" wrt the feed thread extension,
it makes me cringe. By my count, James has 11 drafts in the system,
all Atom-related. Many of them are copies of existing RSS extensions.
It doesn't seem appropriate to issue competing versions of various
extensions from Microsoft, Yahoo et al. and claim they are products of
community consensus, for that excludes the IETF from defining the
problem. It also turns the WG into a factor in silly vendor sports,
which damages WG and IETF credibility.

--

Robert Sayre

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 2 May 2006 04:44:48 +0200

* Robert Sayre <[email-masked]> [2006-05-02 03:50]:
> especially when changes requested by the community are met with
> hostility and channel flooding.

Did this happen in more cases than the one I’m aware of? You
know, the one where James eventually caved on both distinct
points anyway?

> When I read terms like "more standard" wrt the feed thread
> extension, it makes me cringe.

There are obvious reasons why that one is better than the rag-tag
group of RSS extensions required to duplicate even a limited set
of its use cases. We’ve had that discussion in other venues. (If
you do require a blow-by-blow posted here, I can put together a
summary for the WG.)

> By my count, James has 11 drafts in the system, all
> Atom-related. Many of them are copies of existing RSS
> extensions. It doesn't seem appropriate to issue competing
> versions of various extensions from Microsoft, Yahoo et al. and
> claim they are products of community consensus,

Granted, but don’t lump them all together. Some of them *are*
products of community consensus; the Thread extension in
particular got a lot of churn (more than the others by a wide
margin; ~250 posts on this list by my last count, aside from a
dozen weblog threads or so). At least one or two others received
some attention as well (the Licence extension I think? I didn’t
pay much attention to those).

It appears that it would be most productive if you simply express
any specific concerns you have about particular drafts and their
overlap with particular RSS extensions, instead of going for an
ad hominem against James. It worked for David Powell; his
concerns about technical flaws in the Thread extension convinced
James to revise the draft, where your vociferous unsubstantiated
objections had previously failed.

In any case I’m puzzled why you’d start ringing alarm bells just
now. None of these I-Ds are new; they’re all at least several
months old and some have been through a half-dozen revisions and
corresponding announcements. How did they escape your notice for
so long? If they did not, why have they only become a problem
now?

> for that excludes the IETF from defining the problem.

How do you mean? (Question to be taken at face value. I honestly
am not sure what you mean here.)

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

---

From: "Robert Sayre" <[email-masked]>
Date: Mon, 1 May 2006 23:16:04 -0400

On 5/1/06, A. Pagaltzis <[email-masked]> wrote:
> Did this happen in more cases than the one I'm aware of?

Yes.

> group of RSS extensions...

Disagree. There is no proof of that.

> ad hominem against James.

I didn't go for an ad hominem. That would be something like "the feed
draft is bad because James wrote it". I disagree with many decisions
in the draft, but that is because I think they are misguided, not
because I dislike the person who wrote them. For instance, every other
threading extension uses a simple element with a number to represent
the number of responses. This is limited in theory, but in practice,
such elements are so easy to deploy, they prove valuable. In fact, a
few WG members used my unauthorized version of the feed thread
extension to track my comments.

> It worked for David Powell; his

Nonsense. Sylvain pointed out that he was being pushy and ignorant,
and only then did he changed it. I think you're confusing James'
rhetoric with reality. A silly mistake. His rhetoric is pretty clumsy.

> In any case I'm puzzled why you'd start ringing alarm bells just
> now.

I-Ds by themselves are not an issue.Of course, actual change control
is, and documents pushed through the process without
problem-definition in the IETF are much more prone to abuse. It really
does bother me that these documents are being pushed through at the
same level as the Atom draft itself, and I don't think I need to
apologize for my timing.

Anyway, I don't see how the timing of my email is not relevant to the
topic at hand.  Besides, I was b-b-b-banned during lots of it, but
I've getting better at being courteous to the ethically-challenged.

> am not sure what you mean here.)

Defining the charter, etc, etc. It's a good thing to do. Are there any
WG members left who were around at that phase? I joined right around
then...

--

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

---

From: James M Snell <[email-masked]>
Date: Mon, 01 May 2006 22:04:42 -0700

> objections had previously failed.

Speaking of which, I'm not very happy about it, but I just sent off an
updated version of the Feed thread draft for publication that does away
with the thr;count and thr:when attributes on the link and introduces a
thr:replies element.

The example below appears within the updated draft,

   <feed xmlns="http://www.w3.org/2005/Atom"
       xmlns:thr="http://purl.org/syndication/thread/1.0">
       <id>tag:example.org,2006</id>
       <title>Entries and Comments</title>
       ...
       <entry>
         <id>tag:example.org,2006:1</id>
         <title>My Post</title>
         <updated>2006-05-01T08:08:08Z</updated>
         <link rel="replies" href="/comments"
           type="application/atom+xml" />
         <thr:replies ref="tag:example.org,2006:comments"
           label="Comments and Trackbacks"
           count="2" updated="2006-05-01T12:12:12Z"/>
         <thr:replies ref="tag:example.org,2006"
           label="Follow-ups and Corrections"
           count="1" updated="2006-05-01T09:09:09Z" />
         ...
       </entry>
       <entry>
         <id>tag:example.org,2006:2</id>
         <title>My Second Post</title>
         <updated>2006-05-01T09:09:09Z</updated>
         <link rel="replies" href="/comments"
           type="application/atom+xml" />
         <thr:replies ref="tag:example.org,2006:comments"
           label="Comments and Trackbacks"
           count="1" updated="2006-05-01T10:10:10Z" />
         <thr:in-reply-to ref="tag:example.org,2006:1" />
         ...
       </entry>
     </feed>

As you can see from the example, the thr:replies/@ref attribute points
to an atom:id value, and not the URI used by the link.  When going
through and trying to implement the original concept with href, the
xml:base issues proved to be more hassle than it was worth.

Look for the updated draft to publish in the next day or so.

- James

---

From: John Panzer <[email-masked]>
Date: Mon, 01 May 2006 23:37:32 -0700

Robert Sayre wrote:

> .. Are there any

*Holds up hand.  Shrugs. Goes back to work.*

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 2 May 2006 15:47:59 +0200

* James M Snell <[email-masked]> [2006-05-02 07:15]:
> As you can see from the example, the thr:replies/@ref attribute
> points to an atom:id value, and not the URI used by the link.

So fetching and parsing all relevant links is the only way to
know which `thr:replies` element applies to which link, and no
way to indicate a global reply count is available?

Regards,

---

From: James M Snell <[email-masked]>
Date: Tue, 02 May 2006 07:50:13 -0700

Aristotle,

I'm not 100% happy with it yet so it may change at least one more time.
 But I did want to get this out and in front of y'all to get initial
reactions.

I'll go ahead and make the ref attribute optional.  Regarding the ref
vs. href, issue, I really want to discourage client implementors from
using the thr:replies as a link to the comment feed.  Having and href
attribute in there is inviting headaches.  Suggestions on possible ways
of wording the spec / attribute naming / etc would be greatly appreciated.

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 2 May 2006 18:49:02 +0200

* Robert Sayre <[email-masked]> [2006-05-02 05:25]:
> >> especially when changes requested by the community are met
> >> with hostility and channel flooding.
> >

Such as?

> Disagree. There is no proof of that.

There is proof that the existing patchwork of RSS extensions is
insufficient. That is enough to convince me that an extension
which addresses their holes is useful.

If addressing holes in existing standards was unnecessary, then
RSS is good enough and the Atom was a giant waste of time.

> I disagree with many decisions in the draft, but that is
> because I think they are misguided, not because I dislike the
> person who wrote them. For instance, every other threading
> extension uses a simple element with a number to represent the
> number of responses.

That is just one case. I agree that the current setup in the FTE
is less than pretty, and I’d like it to change; but I see what
motivated the form of the provided features and so I consider
them incomplete rather than completely misguided.

> This is limited in theory, but in practice, such elements are
> so easy to deploy, they prove valuable.

I agree with that. (See my proposition elsewhere, which would
have provided this as a special case; it does bother me that the
revision that was just published does not provide for this.)

> >How do you mean? (Question to be taken at face value. I
> >honestly am not sure what you mean here.)
> >
> 
> Defining the charter, etc, etc. It's a good thing to do. Are
> there any WG members left who were around at that phase? I
> joined right around then...

You mean there should be a formal agreed-on statement of what an
I-D is supposed to achieve before the process starts? If that is
what you mean: yes, that is definitely a fine idea.

Regards,

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 2 May 2006 18:54:54 +0200

* James M Snell <[email-masked]> [2006-05-02 17:00]:
> I'll go ahead and make the ref attribute optional.

I think that still needs to be accompanied with verbiage about
global vs local reply count though. There should be guidance on
what it means when elements both with and without `ref`
attributes are present on the same entry.

> Regarding the ref vs. href, issue, I really want to discourage
> client implementors from using the thr:replies as a link to the
> comment feed. Having and href attribute in there is inviting
> headaches. Suggestions on possible ways of wording the spec /
> attribute naming / etc would be greatly appreciated.

Okay, I can see that. Harumpf. Not happy; there has to be a way
to associate links directly with `thr:replies` elements and the
only other way than by comparing `href`s that I can think of is
to put a namespaced attribute on the link, which sucks for
reasons we’ve already been over.

Will have to read this revision and think about it.

Regards,

---

From: "Robert Sayre" <[email-masked]>
Date: Tue, 2 May 2006 13:06:31 -0400

> Such as?

Not appropriate for on-list discussion, sorry.

> RSS is good enough and the Atom was a giant waste of time.

I don't I follow your reasoning. We have namespaces so vendors can
create whatever they might like, without involving the standards
organization. I fail to see the point in rubber-stamping such things.

> what you mean: yes, that is definitely a fine idea.

And WG chairs, etc, etc.

--

Robert Sayre

---

From: James M Snell <[email-masked]>
Date: Tue, 02 May 2006 10:43:15 -0700

>>> Did this happen in more cases than the one I'm aware of?

Aristotle, I appreciate the intention, but please don't bother. It is
painfully clear that Robert has no intention of adding anything of any
real value to the discussion.

As far as FTE is concerned, please understand that I am trying to find
the best way of accommodating a mix between "The simplest thing that
could possibly work" with "The way things likely ought to work".  I
consider MSFT's decision to not preserve unknown foreign content to be
extremely shortsighted.

To contrast, in my implementation, supporting thr:when and thr:count as
attributes on link requires no additional code, I can simply
link.getAttribute(whenQname) and get the info I need.  With the
thr:replies element, to do it properly, I have to create a new extension
element, create a factory, register the extension with the parser, etc.
 Adding in the difficulties inherent in matching equivalent href values
between the atom:link and thr:replies element means that I'm having to
do a whole lot more work than what is required with the attribute
approach.  So much, in fact, that I'm fairly certain that folks will be
less likely to implement a FTE that incorporates the thr:replies
element. So if I seem grumpy and reluctant to change, please try to be
patient and understand.

- James

---

From: "Robert Sayre" <[email-masked]>
Date: Tue, 2 May 2006 14:19:30 -0400

> real value to the discussion.

???

--

Robert Sayre

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 2 May 2006 20:56:55 +0200

* James M Snell <[email-masked]> [2006-05-02 19:45]:
> A. Pagaltzis wrote:
> > Such as?
> 
> Aristotle, I appreciate the intention, but please don't bother.
> It is painfully clear that Robert has no intention of adding
> anything of any real value to the discussion.

I know. However, I despise politics and old boys clubs and prefer
the merit of my decisions to be self-evident, so I’m avoiding any
assumption of any axe to grind behind his behaviour, to see what
should be addressed and how. If there is any meritorious concern
in his objections, I’d like it addressed, regardless (despite?)
of who brought them up and how.

> As far as FTE is concerned, please understand that I am trying
> to find the best way of accommodating a mix between "The
> simplest thing that could possibly work" with "The way things
> likely ought to work".

Absolutely; I pushed for some of the compromises in the current
design myself.

> With the thr:replies element, to do it properly, I have to
> create a new extension element, create a factory, register the
> extension with the parser, etc. Adding in the difficulties
> inherent in matching equivalent href values between the
> atom:link and thr:replies element means that I'm having to do a
> whole lot more work than what is required with the attribute
> approach.

I have to say that your architecture sounds rather heavyweight,
though it could be close to the norm for people who don’t work at
the DOM level. I don’t have experience with that.

To give my experience from the other end, all my work has been at
the DOM level, where the approaches differ only minimally.
libxml2 provides a `getBase` method which makes xml:base support
effortless; when I use XSLT to transform Atom feed documents, I
wrap it and register it as an extension function, so matching
`href`s is trivial:

    <xsl:key
        name="link-to-uri"
        match="atom:link"
        use="uri:resolve( uri:base( . ), @href )"
    />

> So much, in fact, that I'm fairly certain that folks will be
> less likely to implement a FTE that incorporates the
> thr:replies element.

I can see that. Hrmf. There’s gotta be a better way…

I hope though that this also gives you an appreciation for
Robert’s complaint about the lack of a global reply count
provision. He’s right: for simple use cases that sidesteps a lot
of headaches on the consumer’s end.

> So if I seem grumpy and reluctant to change, please try to be
> patient and understand.

Yes, I see now how it comes about.

However, referring to above, plus what we know about the Windows
RSS Platform, please don’t forget the cases other than your own.

Let’s see if we can come up with something that is as simple to
implement as possible for everyone…

Regards,

---

From: "Robert Sayre" <[email-masked]>
Date: Tue, 2 May 2006 15:43:04 -0400

On 5/2/06, A. Pagaltzis <[email-masked]> wrote:
> the merit of my decisions to be self-evident, so I'm avoiding any
> in his objections, I'd like it addressed, regardless (despite?)

I've been saying the same thing for weeks. I suppose it's par for the
course to handwave about them being "strictly advisory", supply
circular definitions for the feature in the first place, claim no one
will be implementing the feature, then claim that someone is, etc,
etc. You know, stuffing an idea because of who proposed it. You can go
read the atom-protocol archives if you want more evidence of that.

The general pattern seems to be to sanctimoniously scold me for making
the suggestion, and then to adopt it with cosmetic changes.

--

Robert Sayre

---

From: James M Snell <[email-masked]>
Date: Tue, 02 May 2006 13:12:56 -0700

A. Pagaltzis wrote:
>[snip]

Heavyweight?  It's Java. need I say more?

By "do it properly", I mean being able to provide developers with an
interface that understands the thread extension, it's a difference between:

Option 1, which does not require adding any additional classes

  ExtensionElement el = entry.getExtension(thrReplies);
  int count = el.getAttribute("count");
  Date updated = AtomDate.valueOf(el.getAttribute("updated"));

and Option 2, which does require adding additional classes

  Replies replies = entry.getExtension(thrReplies);
  int count = replies.getCount();
  Date updated = replies.getUpdated();

My implementation supports either.

Getting the resolved href's for the link and replies is simple.
Matching up all of the various equivalents is a pain.

  URI uri1 = link.getResolvedHref();
  URI uri2 = replies.getResolvedHref();
  // normalize and compare the uri's

>         use="uri:resolve( uri:base( . ), @href )"

Does your implementation properly handle the following (contrived) example:

<entry xml:base="http://example.org/foo/bar">
...
<link href="../comments.xml" rel="replies" />
<thr:replies href="http://EXAMPLE.org:80/foo/bar/../comments.xml" ... />
...
</entry>

I know for a fact that Java's built-in comparison functions for the URI
and URL classes do not.  I have to normalize the URI's after I resolve
them before I can compare them.

What's more, for each replies link, I need to iterate through all
available thr:replies elements, resolve, normalize and compare each href.

Pain.

It is possible that the spec could dictate that the thr:replies resolved
href attribute MUST match the link's href attribute
character-for-character, making the above example invalid.

> I can see that. Hrmf. There’s gotta be a better way…

;-) Yes, there is a better way, but y'all complained about it ;-)

(sorry, couldn't resist)

>[snip]

As always, suggestions for spec text are always welcomed.

oh, and btw, draft -09 is now available.

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

- James

---

From: James M Snell <[email-masked]>
Date: Tue, 02 May 2006 13:17:54 -0700

Just a quick heads up.  To illustrate a simple example of feed rank bein
used, I put together an xslt that renders my Netflix Queue as an Atom
feed using the feed rank, feed history and MSFT simple list extensions.

http://tinyurl.com/nxzgh

Please excuse the tinyurl, the real URL for the feed is big and ugly
because it goes through the W3C online xslt servlet to produce the
result.  You can find the original URL on my blog:
http://www.snellspace.com/wp/?p=312

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 2 May 2006 22:46:10 +0200

* Robert Sayre <[email-masked]> [2006-05-02 22:00]:
> I've been saying the same thing for weeks. I suppose it's par
> for the course to handwave about them being "strictly
> advisory", supply circular definitions for the feature in the
> first place, claim no one will be implementing the feature,
> then claim that someone is, etc, etc.

Yes. I thought those defences were very silly as well.

> You know, stuffing an idea because of who proposed it.

No, not just because of who proposed it, but also because of how.
You objection is not unreasonable, but you phrased it roughly as
“this is useless crap that no consumer is going to want and only
clueless publishers would insist on providing.” What is anyone
supposed to draw from that? Nor did it help to interpret this on
the level of vendor politics: implying that this extension came
to be just because IBM doesn’t want to play ball wasn’t the most
precise way to clarify its flaws. It wasn’t until David gave his
criticism that I saw any serious problem. 

Regards,

---

From: "James Holderness" <[email-masked]>
Date: Tue, 2 May 2006 22:06:51 +0100

Just looking at that example, it seems to me that an aggregator that 
implements Microsoft's simple list extensions would get a full-featured 
representation of that feed without having to know anything at all about 
feed rank and feed history. So why bother with them?

I'm sure you can come up with cases which couldn't be handled perfectly by 
SLE (which I'd be the first to admit is a pretty lousy spec), but it's out 
there now and it more or less works. Does feed rank really offer you so much 
more that it justifies a competing extension?

Regards
James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 2 May 2006 23:45:50 +0200

> Heavyweight?  It's Java. need I say more?

Hehe. I stopped just short of asking “is that in Java?” :-)

> <thr:replies href="http://EXAMPLE.org:80/foo/bar/../comments.xml" ... />

You probably wanted a trailing slash on your base URI, else the
two hrefs are different.

> I know for a fact that Java's built-in comparison functions for
> the URI and URL classes do not.  I have to normalize the URI's
> after I resolve them before I can compare them.

Yeah, I need to do some extra work. I’m using Perl, whose URI
module does most of the work, but not all. Downcasing the host
name, removing explicit default ports, unescaping characters
which can be, and some scheme-specifics are all automatic, but
some things that should be (at least resolving `..` path segments
and escaping slashes in the query string) are not.

I should probably read the relevant RFCs and write test cases,
then file tickets… that stuff is bothersome.

> What's more, for each replies link, I need to iterate through
> all available thr:replies elements, resolve, normalize and
> compare each href.
> 
> Pain.

Yeah. At the DOM level you could use XPath to avoid iterating… :-/

> It is possible that the spec could dictate that the thr:replies
> resolved href attribute MUST match the link's href attribute

That would be a solution. Would it be a burden on publishers?

> ;-) Yes, there is a better way, but y'all complained about it

Don’t be bitter now. :-)  That particularly choice does make
particular sense in your case; but that doesn’t mean it’s the
overall best.

Regards,

---

From: James M Snell <[email-masked]>
Date: Tue, 02 May 2006 15:39:06 -0700

James Holderness wrote:
> feed rank and feed history. 
> 

That's part of the point, actually.  The extensions can work
cooperatively with or independently of one another.

> So why bother with them?

The Feed history <complete /> element and SLE's
<cf:treatAs>list</cf:treatAs> directly compete with one another, with
the exception that treatAs also defines that ordering of the entries is
important.

Feed Rank operates orthogonally to both.

> I'm sure you can come up with cases which couldn't be handled perfectly
> by SLE (which I'd be the first to admit is a pretty lousy spec), but
> it's out there now and it more or less works. Does feed rank really
> offer you so much more that it justifies a competing extension?
> 

To understand where the value of Feed Rank comes in, consider adding
additional ranking dimensions to each entry.  For instance, an entry
might contain a position rank, an average five star review rank, a
average-review-from-my-friends rank, a critics ranking, a popularity
ranking (e.g. number of times the movie has been rented in the last
month), etc.

 <entry>
   ...
   <r:rank label="Queue Position"
           scheme="tag:example.org,2006:queue">1</r:rank>
   <r:rank label="Average reviews (everyone)"
           domain="tag:example.org,2006:reviews"
           scheme="tag:example.org,2006:reviews/all">3.5</r:rank>
   <r:rank label="Average reviews (friends)
           domain="tag:example.org,2006:reviews"
           scheme="tag:example.org,2006:reviews/friends">2.5</r:rank>
   <r:rank label="Average reviews (critics)
           domain="tag:example.org,2006:reviews"
           scheme="tag:example.org,2006:reviews/critics">3.0</r:rank>
   <r:rank label="Total rentals this week"
           domain="tag:example.org,2006:rentals"
           scheme="tag:example.org,2006:rentals/week">5</r:rank>
   <r:rank label="Total rentals this month"
           domain="tag:example.org,2006:rentals"
           scheme="tag:example.org,2006:rentals/month">50</r:rank>
   <r:rank label="Total rentals this year"
           domain="tag:example.org,2006:rentals"
           scheme="tag:example.org,2006:rentals/year">500</r:rank>
   <r:rank label="Current queues (everyone)"
           domain="tag:example.org,2006:queued"
           scheme="tag:example.org,2006:queued/all">40</r:rank>
   <r:rank label="Current queues (friends)"
           domain="tag:example.org,2006:queued"
           scheme="tag:example.org,2006:queued/friends">2</r:rank>
   ...
 </entry>

In this sense, feed rank shares a closer relationship to atom:category
than it does to SLE.

With SLE, each sort key can appear only once within an entry.  In order
to implement the example above, you would have to create a new
namespaced extension element for each dimension you wish to sort on (not
necessarily a bad thing, but opens the door to having multiple
independent and non-interoperable vendor-specific namespaces that all
implement the same basic feature in slightly different ways). With Feed
Rank, we can have as many dimensions as we want, with a consistent
definition and processing model for each, without having to define a new
namespaced extension element for each dimension.

Further, SLE operates only on a single feed document.  Feed Rank is
capable of spanning multiple feed and/or entry documents, regardless of
whether they are pages in a single logical feed or are completely
independent of one another.  For instance, a school could offer one feed
for each class in which each entry represent a test grade for an
individual student.

  <feed>
    <title>Class 1</title>
    ...
    <entry>
      ...
      <r:rank label="1"
              domain="tag:example.org,2006:grades"
              scheme="tag:example.org,2006:grades">1.0</r:rank>
    </entry>
    <entry>
      ...
      <r:rank label="1-"
              domain="tag:example.org,2006:grades"
              scheme="tag:example.org,2006:grades">1.3</r:rank>
    </entry>
  </feed>

  <feed>
    <title>Class 2</title>
    ...
    <entry>
      ...
      <r:rank label="4"
              domain="tag:example.org,2006:grades"
              scheme="tag:example.org,2006:grades">4.0</r:rank>
    </entry>
    <entry>
      ...
      <r:rank label="4-"
              domain="tag:example.org,2006:grades"
              scheme="tag:example.org,2006:grades">4.3</r:rank>
    </entry>
  </feed>

  <feed>
    <title>Class 3</title>
    ...
    <entry>
      ...
      <r:rank label="1"
              domain="tag:example.org,2006:grades"
              scheme="tag:example.org,2006:grades">1.0</r:rank>
    </entry>
    <entry>
      ...
      <r:rank label="2+"
              domain="tag:example.org,2006:grades"
              scheme="tag:example.org,2006:grades">1.7</r:rank>
    </entry>
  </feed>

Using Feed Rank, you could choose to sort the student entries within a
single class feed (e.g. who are the top students in Class 1), or produce
a combined view spanning all three feeds (e.g. who are the top students
at the school).

Also, with the SLE, the ordering is dependent on the feed in which the
entry appears.  Pass the entries through an aggregator (e.g. Sam's
http://planet.intertwingly.net) and the order of the entries may change,
breaking your list.  With Feed Rank, the ranking value is attached to
the entry, meaning that even if the entries are copied into aggregate
feeds, reordered, etc, the original sort order can be reconstructed.

Again, however, Feed Rank is not intended to compete with the simple
list extensions.  They serve different purposes.  SLE defines a
processing model for individual feed documents whose entries represent a
sorted list; Feed Rank defines a way of assigning numeric rankings to
entries to facilitate sorting and grouping.

- James

---

From: David Powell <[email-masked]>
Date: Wed, 3 May 2006 00:05:32 +0100

> <thr:replies href="http://EXAMPLE.org:80/foo/bar/../comments.xml" ... />

I don't think you should do URI normalisation. The ref is being used
as an identifier, you don't do protocol level normalisation on
namespace URIs or Atom ids why do it here? The draft should specify
character-by-character comparison of the resolved URI's.

[Er, I mean IRI. Everyone's using IRI datatypes, right?...]

-- 
Dave

---

From: "Robert Sayre" <[email-masked]>
Date: Tue, 2 May 2006 19:28:45 -0400

> entries to facilitate sorting and grouping.

I find this explanation most unconvincing. Near as I can tell, this
spec serves an identical purpose, but it's much less flexible.

   In the Atom Syndication Format [RFC4287], the order of entries as
   presented in a feed is typically considered to be insignificant.
   This presents a challenge when the set of entries is intended to
   represent an ordered or ranked list.  This document specifies an
   extension...

Seems to me it's pretty darn similar.

--

Robert Sayre

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 3 May 2006 01:45:46 +0200

Hi David,

* David Powell <[email-masked]> [2006-05-03 01:15]:
> I don't think you should do URI normalisation. The ref is being
> used as an identifier, you don't do protocol level
> normalisation on namespace URIs or Atom ids why do it here?

That’s a good point; though there’s a slight difference as
namespace URIs must be absolute in the first place.

The `href` isn’t necessarily unique, now that I think about it,
if you play games with `xml:base`:

    <link href="comments.xml" rel="replies" />
    <link href="comments.xml" rel="replies" xml:base="./foo/" />

Of course, it’s entirely reasonable to declare this madness and
refuse to support it.

Maybe we need something like _A Plea for Sanity_ that Joe English
wrote about namespaces, for xml:base.

> The draft should specify character-by-character comparison of
> the resolved URI's.

Yeah, probably.

Regards,

---

From: "Robert Sayre" <[email-masked]>
Date: Tue, 2 May 2006 21:03:45 -0400

> Yes. I thought those defences were very silly as well.

Not only were they "very silly", they're offensive. It's as if any
truthy sounding answer is enough to brush someone off. If it's a WG
draft, and not individual draft, you have to repeat the
truthy-sounding answers every day for months on end. Also, it pays to
scream bloody murder when someone gets upset with you. Also, it pays
to make lots of irrelevant changes and claim to be responding to
feedback.

Of course, our chairs have made it abundantly clear that this sort of
offensive, dishonest, repugnant delay tactic is perfectly acceptable,
and must be treated with respect. Well, I won't use a four-letter word
this time, but let's just say I'd rather deal with Microsoft than the
IETF at this point.

> No, not just because of who proposed it, but also because of how.

Sorry Aristotle, you're not qualified to make that statement. I've
proposed things every which way, so I know the form doesn't matter.

--

Robert Sayre

---

From: James M Snell <[email-masked]>
Date: Tue, 02 May 2006 18:31:46 -0700

Ok, so how's this (not word-for-word as I would write it in the spec,
but you should get the idea)

The ref attribute MUST be an absolute URI that matches a the resolved
href URI of a replies link character-for-character (case sensitive)

In other words;

<link rel="replies" href="comments.xml"
      xml:base="http://example.org/foo" />
<thr:replies ref="http://example.org/comments.xml" ... />

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 3 May 2006 05:44:07 +0200

* Robert Sayre <[email-masked]> [2006-05-03 03:15]:
> Sorry Aristotle, you're not qualified to make that statement.
> I've proposed things every which way, so I know the form
> doesn't matter.

Indeed, I’ve only been a witness to the discussion in a few
venues, so I can’t pass judgement about the big picture. I have
to take your word for it.

However, with regard to the part of the picture in which I did
participate, I will go on record to say that you almost never
made it easy for me to consider your position on an issue on
which I was trying to make up my mind when held a strong opinion
about it. And that’s not for lack of willingness on my part, nor
is it because your positions have been unreasonable. I often
wished you’d argue your case better.

Regards,

---

From: Andreas Sewe <[email-masked]>
Date: Wed, 03 May 2006 11:32:12 +0200

Robert Sayre wrote:
> James M Snell wrote:
>> Again, however, Feed Rank is not intended to compete with the 
>> simple list extensions.  They serve different purposes.  SLE 
>> defines a processing model for individual feed documents whose 
>> entries represent a sorted list; Feed Rank defines a way of 
>> assigning numeric rankings to entries to facilitate sorting and 
>> grouping.
> 
> presented in a feed is typically considered to be insignificant. This
> presents a challenge when the set of entries is intended to 

Your observation is correct. However, this only means that we need to
revise Feed Rank's introductory section to state its use applications
clearly. The second sentence of the introduction, which you
unfortunately dropped in your quote, should definitly mention the fact
that Feed Rank allows several, independent order relations to be defined
on the set of entries.

    ... This document specifies an extension that allows feed publishers
    to establish numeric rankings for entries within a feed to be used as
    a means of organizing and sorting those entries.

IMHO, the following would be an improvement on this, highlighting the
purpose Feed Rank is meant to serve:

    This document specifies an extension that allows feed publishers to
    establish one or more numeric rankings for entries within a feed,
    each of which can be used, independently or in conjunction with the
    others, to sort those entries according to different criteria.

But does this sound like an improvement to you, too?

Best wishes,

Andreas Sewe

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 3 May 2006 09:22:23 -0700

At 9:03 PM -0400 5/2/06, Robert Sayre wrote:
>If it's a WG
>draft, and not individual draft,

It is an individual draft.

>Of course, our chairs have made it abundantly clear

I'm not sure that Tim and I have made much abundantly clear in a while.

>but let's just say I'd rather deal with Microsoft than the
>IETF at this point.

Works for me.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Robert Sayre" <[email-masked]>
Date: Wed, 3 May 2006 12:35:51 -0400

> Works for me.

<http://www.alvestrand.no/pipermail/problem-statement/2003-March/000951.html>
--

Robert Sayre

---

From: "Robert Sayre" <[email-masked]>
Date: Wed, 3 May 2006 14:02:26 -0400

> But does this sound like an improvement to you, too?

Sort of. I did a deep dive on this, and I think it's really huge. It's
had little community input, it's not at all clear that the approach is
correct, and it's not clear that clients will implement it, as the
space is so new. However, I do understand you want to ship something,
and it's nice that you want to document it openly. So, Information or
Experimental seems like a good fit here.

I think the document needs *a lot* of work. My comments follow:

draft-index-09:
> 1.  Introduction
>    extension that allows feed publishers to establish numeric rankings
>    for entries within a feed to be used as a means of organizing and
>    sorting those entries.

Even with the alternative intro you've supplied, it's not clear what
problem this document solves. It seems to claim almost unlimited
powers. :) There are quite a few sections that seem to have a very low
return to me. I think you need to cut, and cut a lot. I think the
value evaporates very quickly outside of the 'ranking' element.

>    The XML Namespaces URI [W3C.REC-xml-names-19990114] for the XML
>    elements and attributes described in this specification is:
>      http://purl.org/syndication/rank/1.0

Is this an appropriate namespace for an IETF document?

>
> 3.  Ranking Domains and Schemes
>
>    A "Ranking Domain" is a uniquely identifiable logical set of entries
>    with associated numeric ranking values.

I can parse the sentence, but I don't understand what this means.

>    A "Ranking Scheme" identifies specific rules on how to interpret the
>    numeric ranking values within one or more "Ranking Domains".

Same here. I suggest avoiding the new terminiology. A more
plain-spoken, concrete, operational approach would work better.

> 3.1.  The 'r:scheme' Element
>
>    Ranking Schemes are defined using the r:scheme element.  A scheme
>    includes zero or more r:value and r:range elements that define the
>    set of possible values for the Ranking Scheme.
>
>      rankingScheme = element r:scheme {
>        atomCommonAttributes,
>        attribute name { IRI }?,
>        attribute label { text }?,
>        attribute significance { 'ascending' | 'descending' }?,
>        ( value | range )*
>      }
>
>    The "name" attribute provides a universally unique identifier for the
>    scheme in the form of an absolute IRI.

This conflicts with the atom:author field. Why not @id, @domain, etc.

>    The "label" attribute specifies a Language-Sensitive, human-readable
>    label for the scheme.

OK...

>    The "significance" attribute indicates how implementations are to
>    interpret the significance of a numeric ranking value.  A value of
>    "descending" indicates that the significance of the rank decreases as
>    the numeric ranking value increases.  A value of "ascending"
>    indicates that the significance of the rank increases as the numeric
>    ranking value increases.  If not specified, the significance is
>    considered to be "ascending".

@significance is also confusing. Suggest changing to @order or similar.

>    An Atom feed element MAY contain any number of r:scheme elements.  A
>    feed MUST NOT contain more than one r:scheme element with the same
>    name.

Well, you have all of these child elements that can change the effect
of the element, so why would you want to ban this behavior?

>        <r:scheme
>          name="tag:example.org,2006:movie_reviews"
>          xml:lang="en-us"
>          label="Five Star Reviews"
>          <r:range scale="1"
>                   step="0.5"
>                   minimum="0.0"
>                   maximum="5.0" />

This example is confusing because you haven't defined r:range yet. I
also suggest grouping some attributes on the same line, if possible.

> 3.1.1.  The 'r:value' and 'r:range' Elements
>
>    A Ranking Scheme is defined by a collection of zero or more r:value
>    and r:range elements that constrain the set of values considered
>    significant by the Scheme.

>    The value element defines a discreet decimal value.  The element's
>    content value MUST NOT contain and leading or trailing whitespace.

'discreet decimal value' is underspecified. UPDATE: I see you define
it later. I suggest using xsd:decimal in the RNC and calling out XML
Schema Datatypes at this point.

>      value = element r:value {
>        atomCommonAttributes,
>        attribute label { text }?,
>        attribute scale { decimal }?,
>        ( decimal )
>      }
>
>    The value element is useful for defining Ranking Schemes consisting
>    of a set of absolute values as in the example below,

This seems really complicated to me. It's not clear to me how an
application would apply this data, though I admit to having a fuzzy
notion.

>    The range element defines a range of decimal values that MAY be
>    bounded by minimum and maximum values.

Explain the consequences of including or omitting a boundary.

>
>    The "scale" attribute on both the value and range elements specifies
>    the total number of decimal digits to the right of the decimal
>    indicator in the value of the numeric ranking value.  The scale is

I don't understand this.

>
>    expressed as a non-negative integer.  If not specified, the value is
>    considered to be zero.  Ranking Schemes that are based on fractional
>    numeric ranking values SHOULD specify a scale.  Numeric ranking
>    values that use a larger scale than defined for the scheme MUST be
>    rounded to the nearest in-scale value (e.g. with scale=2, the rank
>    0.123 is rounded down to 0.12, the rank 0.125 is rounded up to 0.13.)
...
>    The "step" attribute specifies the minimum significant increment for
...
>    The "origin" attribute specifies the base from which steps in a range
...
>    Ranges and values defined within a Scheme MUST NOT overlap one
>    another.

This section is really, really dense. I have a hard time understanding
any of it. Perhaps some Excel-like ASCII table illustrations would
help.

>     rankingValue = element r:rank {
>        atomCommonAttributes,
>        attribute domain { IRI }?,
>        attribute scheme { IRI }?,
>        attribute label { text }?,
>        { decimal }
>      }

Given this definition, it's not clear to me why the feed-level stuff
is necessary. Is the idea that clients have to know that to edit?

>    Ranking Domains group entries with attached numeric ranking values to
>    logical sets.  Ranking Domains are uniquely identified by IRIs.

"Ranking Domains" come back to haunt us. I'm lost here.

>    Domain Scopes SHOULD be considered open sets consistings of entries
>    from any number of feeds.

More strange terminology.

>    Processing a Ranking Domain to produce an ordered set involves the
>    following steps:
>    o  Select the Ranking Scheme.
>    o  Identify the Ranking Domain
>    o  Identify the available set of entries containing numeric ranking
>       values within the identified Ranking Domain using the selected
>       Ranking Scheme.
>    o  Remove from the set all entries whose rankings fall outside the
>       minimum and maximum values set by the selected Ranking Scheme.
>    o  Sort the remaining set of ranked entries according to the
>       significance and step of the numeric ranking as defined by the
>       Ranking Scheme.

Ah, some enlightenment here. You definitely need to get this text up
front, expand it, and intersperse this text with illustrations. This
is the text that tells implementers what they're supposed to do.

>    Feeds MAY contain ranked entries that have no specified scheme.  In
>    such cases the Default Ranking Scheme should be applied.

This seems like overkill.

>    The Default Ranking Scheme assumes ascending significance and a
>    single range with no minimum or maximum value, no significant step,
>    unspecified scale, and an origin of 0.

Oh wait, is this the introduction of this term? It doesn't seem useful
to me. I suggest text along the lines of "If there is no scheme
specified, [explain default processing]." No terminology necessary.

> 8.  Well-Known Ranking Schemes
>
>    Feeds MAY contain ranked entries whose ranking scheme cannot be
>    resolved (i.e., no r:scheme with a "name" attribute matching the
>    rankings "scheme" attribute can be found).  In such cases software
>    implementations MAY attempt to match such rankings to well-known
>    schemes.  For instance, an online search engine may choose to define
>    a ranking scheme that is reflective of the relevance of a given
>    result to a search query; rather than require that a r:scheme element
>    be included in every feed where the Ranking Scheme may be used, the
>    search engine may separately publish its Ranking Scheme and
>    associated Ranking Domain.  (The format of such a publication is
>    beyond the scope of this specification.)
>
>    A hypothetical search engine ranking using a well-known scheme
>
>      <r:rank scheme="http://search.example.org/relevance">5</r:rank>
>
>    If a Ranking Scheme cannot be resolved this way (e.g., no r:scheme
>    with a matching "name" attribute can be found and the scheme is not
>    well-known), the Default Ranking Scheme should be applied.
>
>    Further, it is possible that a processor may resolve multiple Ranking
>    Schemes for a given Ranking.  For instance, a feed may contain an
>    "r:scheme" that redefines a scheme well-known to the processor.  In
>    such cases, processors should issue a warning to the user.

This capability seems like total overkill.

>
>    Because this specification defines an extension to the Atom
>    Syndication Format [RFC4287], it is subject to the same security
>    consideration as defined in section 8 of that specification.
>
> Appendix A.  Acknowledgements
>
>    The authors gratefully acknowledge the feedback from the Atom
>    Publishing working group during the development of this
>    specification.

You should also acknowledge verbatim copies of text from RFC4287.

--

Robert Sayre

---

From: David Powell <[email-masked]>
Date: Wed, 3 May 2006 20:31:09 +0100

> feed rank and feed history. So why bother with them?

I made a suggestion for avoiding implicit ordering in SLE on the
FEED-TECH list[1]. Basically to allow the cf:treatAs to use the
@element and @data-type attributes that are used in cf:sort and
cf:group elements, so that entries could include a datestamp, or
index, which could be used for the ordering of the list rather than
the natural ordering.

[1] http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0603d&L=feed-tech&T=0&F=&S=&P=312

Actually - can cf:list be used together with cf:sort@default='true'?,
I think I'll ask...

-- 
Dave

---

From: Sean Lyndersay <[email-masked]>
Date: Wed, 3 May 2006 18:59:12 -0700

David,

Looks like I picked a good time to catch up on Atom-syntax mail.

> Actually - can cf:list be used together with cf:sort@default='true'?,

Yes, it can. See the example in the explanatory doc we posted a while back.
http://blogs.msdn.com/rssteam/articles/SimpleListExtensionsExplained.aspx

That example feed is online here:
http://sean.members.winisp.net/lists/bookexample.xml

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Powell
Sent: Wednesday, May 03, 2006 12:31 PM
To: James Holderness
Cc: atom-syntax
Subject: Re: Atom Rank Extensions

--
Dave

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 4 May 2006 14:57:54 +0200

* James M Snell <[email-masked]> [2006-05-03 03:45]:
> Ok, so how's this (not word-for-word as I would write it in the
> spec, but you should get the idea)
> 
> The ref attribute MUST be an absolute URI that matches a the
> resolved href URI of a replies link character-for-character
> (case sensitive)
> 
> In other words;
> 

I don’t know if I like it. It really, *really* departs from
“something that’s as simple to implement as possible,” doesn’t
it? Not only is this just as hard for consumers to implement as
previous sketches, it’ll *also* annoy publishers, I think.

Question: what is the reason you are so staunchly opposed to
cloning `atom:link` for the extension’s purposes?

I’m starting to think that that is the only sane answer. If you
want to provide additional information about a link, you need to
associate this information with the link somehow. If you want to
stick to the spec mechanisms for extending the format, then you
have to provide this information in extension elements and you
must not add attributes to the link. So you must identify the
link by one of its attributes. The only attribute of `atom:link`
by which you can identify it at all is `href`. However, if you
factor in xml:base, you’re in a world of pain, and I don’t see
any way out of that.

The only other option I see is a very ugly hack: ride on the back
the `rel` attribute, abusing the fact that a relation may be a
URI to provide an identifier, ie. something like

    <link
        rel="http://purl.org/net/thread/replies?id=x3os882ja"
        href="comments.atom"
        ...
    />

But that’s so awful and dirty on so many levels that that I have
to go wash my hands now. Ugh.

Regards,

---

From: James M Snell <[email-masked]>
Date: Thu, 04 May 2006 08:47:59 -0700

> previous sketches, it’ll *also* annoy publishers, I think.

Yep.

> cloning `atom:link` for the extension’s purposes?

I am very much against the idea of encouraging extension developers to
go off and clone core Atom elements whenever they want to provide some
additional piece of information.  e.g., Say I create a thr:link.  what
value would that add to end users and feed reader implementors?
OpenSearch already has their own os:link.  Gdata has entryLink and
feedLink (which aren't clones of atom:link, but are still links
nonetheless). The more we clone and duplicate the function of atom:link,
the less valuable and useful atom:link becomes, and the more we put
undue burden on feed consumers.

> I’m starting to think that that is the only sane answer. If you

The only sane answer would have been to make link extensible.  If I
thought it would actually be a fruitful exercise, I would suggest that
we amend rfc4287 to make it extensible, per section 4.1.1 of RFC2026:

   A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.  However, further experience
   might result in a change ... of the specification
   before it advances.

However, for now, I think I'll proceed by simply dropping the count and
when from the draft.  The folks who want those things can add them back
under a different namespace.  It's not worth chasing our tails over two
pieces of optional metadata.  I've already prepared a draft -10 that
removes the attributes complete, I just haven't sent it off yet.

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 4 May 2006 19:19:07 +0200

* James M Snell <[email-masked]> [2006-05-04 18:00]:
> The only sane answer would have been to make link extensible.

There’s no doubt about that at this point. Non-extensibility of
links has caused us a lot of pain in several different extensions
at this point.

Unfortunately, only hindsight is 20/20…

> However, for now, I think I'll proceed by simply dropping the
> count and when from the draft.

Okay. It’s a pity, since folks were obviously getting value from
that information, but it’s an acceptable move.

Regards,

---

From: "M. David Peterson" <[email-masked]>
Date: Thu, 4 May 2006 15:18:01 -0600

Just a note:  When you consider that what people gain is, in essence, a
simplified way to gain access to information that is otherwise accessible,
just at a higher over-the-wire , and processor intensive cost, then it makes
a lot of sense to create an extensible namespace/specification devoted
strictly to these types of things.  This would allow for at least two
things:

- the ability for experience "from-the-field", or in other words, areas of
optimization and/or convenience that have been discovered past the point of
a specification last-call, and yet add value to more than one implementor,
and as such justification for collaboration on how to go about things in a
way that makes sense to more than one implementor.

- The ability to push off controversial, questionable, and/or just plain
ugly pieces of any given spec that do little more than cause a need for the
spec editor to spend a bit of time to pre-funk before approaching his/her
inbox, knowing exactly what it is that requires him/her to get half way to
his/her home office before returning to the fridge for an extra two bottles
to kill the pain thats bound to ensue WELL after the pre-funk has worked its
way through the system. ;)

Something like this could start at the Atom wiki with a
"PostSpecOptimizations" page set-up where folks can attach data sheets with
test results, or real world use-case studies that showcase needs in
particular areas that are not enough to justify their own spec, but enough
to offer gains to the community as a whole, and as such, justification to
work in a more centralized manner such as this list once it has gotten past
the "yeah, this makes sense to me too... lets propose it" stage.

Or is something like this simply inviting WAY TOO MANY little things to find
justification to plug up the collective inbox of the community members?

On 5/4/06, A. Pagaltzis <[email-masked]> wrote:
> There's no doubt about that at this point. Non-extensibility of
> Okay. It's a pity, since folks were obviously getting value from
> that information, but it's an acceptable move.
>
> Regards,
> --

--
<M:D/>

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

---

From: "Thomas Broyer" <[email-masked]>
Date: Fri, 5 May 2006 00:43:11 +0200

2006/5/2, James M Snell <[email-masked]>:
> Regarding the ref vs. href, issue, I really want to discourage client
> implementors from using the thr:replies as a link to the comment feed.

Why?

From what I read this week in other threads (about cloning the
atom:link element, etc.), I think it could work.

1. define a "replies" link relation, so there is an atom:link pointing
to the replies feed
2. define a thr:replies element with an @href and additional metadata
(count, updated), clients are invited to use the thr:replies/@href and
*not* to try to match the thr:replies element with an
atom:link[@rel="replies"] ; if a "reader" processes thr:replies
elements it should then ignore each and every
atom:link[@rel="replies"].

Step 1 is either optional (do not define this "replies" link relation)
or mandatory (require that there is an atom:link[@rel="replies"]
matching each thr:replies element).

Those three elements would have equivalent meaning, the last one
adding extra metadata:
<atom:link rel="replies" href="comments.atom" />
<thr:replies href="comments.atom" />
<thr:replies href="comments.atom" count="5"
updated="2006-05-05T00:38:00+01:00" />

Things would have been far easier if either a) atom:link were
extensible or b) xml:base wasn't allowed on every element but only on
"sections" (namely, atom:feed, atom:entry and atom:content) that can
be included from other documents, so that you don't have to rewrite
relative IRIs (I think that's the original rational behind xml:base),
but that's not the case…

To conclude, I think using attributes directly on atom:link is the
thing to do, waiting for an amendment to RFC4287 to invite
processors/parsers not to discard that extra metadata. The other
choice is to totally remove those attributes, which is what you
finally chose, I can't blame you.

--
Thomas Broyer

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 5 May 2006 01:20:25 +0200

* M. David Peterson <[email-masked]> [2006-05-04 23:30]:
> Or is something like this simply inviting WAY TOO MANY little
> things to find justification to plug up the collective inbox of
> the community members?

I don’t know. So far during extension development discussions,
only the missing extensibility for links has stuck out as a real
sore point in RFC 4287. Other than that, the spec has stood up
very well with only a few minor errata reported here and there.

At least, that’s my impression; I don’t know what others think,
of course.

Frankly, I would hope there won’t be much interest – cause if
there is, what else would that mean than that we did a shoddy
job? :-)

Regards,

---

From: Tim Bray <[email-masked]>
Date: Thu, 04 May 2006 16:34:10 -0700

On May 4, 2006, at 3:43 PM, Thomas Broyer wrote:

> extensible

This assertion that atom:link is not extensible is simply, flatly,  
completely, wrong.  I just went and reviewed 4287 and I think it is  
perfectly clear on this.  I suggest that interested parties review  
sections 4.2.7, 6.3, and 6.4 and, if they still think there is any  
problem with child elements of <atom:link>, find language in the RFC  
which says something other than what those sections say. -Tim

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 5 May 2006 02:08:08 +0200

* Tim Bray <[email-masked]> [2006-05-05 01:50]:
> This assertion that atom:link is not extensible is simply,
> flatly, completely, wrong. I just went and reviewed 4287 and I
> think it is perfectly clear on this. I suggest that interested
> parties review sections 4.2.7, 6.3, and 6.4 and, if they still
> think there is any problem with child elements of <atom:link>,
> find language in the RFC which says something other than what
> those sections say.

The assertion is not that atom:link may not have child elements
or namespaced attributes. The assertion is that the list of
locations for Metadata elements in Section 6.4 should have
included atom:link.

Regards,

---

From: "Robert Sayre" <[email-masked]>
Date: Thu, 4 May 2006 20:13:49 -0400

On 5/4/06, Tim Bray <[email-masked]> wrote:
> completely, wrong.

I agree that it's not an especially convincing or interesting
argument, given that 6.4 starts with

"Atom allows foreign markup anywhere in an Atom document"

We certainly don't want consumers to barf on foreign markup anywhere,
so it has to be allowed everywhere. Of course, you'd be foolish to put
extension attributes on things like atom:updated, and lots of other
places, because then you're going to force people to dive into the
feedparser/feedtools/gdata/etc implementation layer. Secondly, we
might not like it for strange pseudo-nationalistic reasons, but some
implementers find it convenient to transcode Atom to RSS2. when you're
doing that, it's more difficult to preserve markup in areas left
undefined by the specification. If you want to make a point, and carp
on how crappy those applications are, you'll look for an excuse to do
it. In reality, those extension points haven't proven that interesting
or necessary, and the current thread is a particularly forceful
example of that reality for those of who aren't participating. So, it
really is that most common of syndication archetypes: the tempest in a
teacup.

--

Robert Sayre

---

From: "Kyle Marvin" <[email-masked]>
Date: Thu, 4 May 2006 19:25:58 -0500

> which says something other than what those sections say. -Tim

I'll admit that I was unclear on this point:  the motivation behind
sometimes using 'extensionElement' and other times 'undefinedContext'
in the Relax-NG schemas for various 4287 elements is a point of
confusion.

But as Tim says, literally speaking I don't think either one precludes
elements in a foreign namespace.

-- Kyle

---

From: Tim Bray <[email-masked]>
Date: Thu, 04 May 2006 18:42:16 -0700

On May 4, 2006, at 5:25 PM, Kyle Marvin wrote:

> the motivation behind

Agreed.  Fortunately the schema's non-normative. -Tim

---

From: Tim Bray <[email-masked]>
Date: Thu, 04 May 2006 18:43:41 -0700

> locations for Metadata elements in Section 6.4 should have

Mountain, meet molehill.

If it turns out to be useful, it'll stick.  Otherwise not. -Tim

---

From: James M Snell <[email-masked]>
Date: Thu, 04 May 2006 19:10:51 -0700

Tim,

Just to be clear, when I say that link should have been extensible, I
mean that link should have used extensionElement* rather than
undefinedContent.  In fact, to be completely honest, I don't think
undefinedContent should have been in the spec at all.  atom:link and
atom:category are the only two elements that use it, and there does not
appear to be any rationale given as to why.

With that said, the real question here is not whether namespaced
attributes and elements can or can not appear on the atom:link element.
 As you point out, and as I've mentioned in the past, the spec is very
clear on this point.  At issue is whether or not authors of standardized
extensions should extend elements with undefinedContent when we know
full well that there are API implementations out there that have made
the extremely shortsighted decision to completely ignore such content.

- James

p.s. I wonder how many folks realize that the following examples are
perfectly legal and valid according to the spec.

  <link href="http://example.org/foo">This is some text</link>

  <link href="http://example.org/foo>
    <b xmlns="http://www.w3.org/1999/xhtml">Foo!</b>
  </link>

  <category term="foo">
    This entry belongs to category
    <xhtml:a href="/blog/categories/foo">foo</xhtml:a>!
  </category>

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 5 May 2006 04:09:15 +0200

* Tim Bray <[email-masked]> [2006-05-05 03:50]:
> If it turns out to be useful, it'll stick. Otherwise not.

No doubt; but then why did we need so much verbiage in Sec. 6.4.
and subsections anyway?

Regards,

---

From: Tim Bray <[email-masked]>
Date: Thu, 04 May 2006 20:05:15 -0700

On May 4, 2006, at 7:10 PM, James M Snell wrote:

> At issue is whether or not authors of standardized

Give me a break, we're in the first *days* of something that will be  
used for at least decades.  Todays' APIs will have a vanishingly- 
small lifespan in comparison; crippling our expressiveness in  
deference to them is, frankly, silly. -Tim

---

From: Andreas Sewe <[email-masked]>
Date: Fri, 05 May 2006 11:18:35 +0200

Robert Sayre wrote:
> Andreas Sewe <[email-masked]> wrote:
> Sort of. I did a deep dive on this, and I think it's really huge.
> It's had little community input, it's not at all clear that the
> approach is correct, and it's not clear that clients will implement
> it, as the space is so new.

I am inclined to agree with your diagnosis that the spec is quite
heavyweight for what looks seemingly like a rather straight-forward
task, namely ordering entries. And the draft has indeed gained some
weight after I joined James as a co-author. :-(

This is mostly due to the fact that we tried to cover one use case,
which seemed to us like the archetypical case of rankings: grades. So we
had a look at the different grading schemes out there at schools and
universities worldwide (thanks to wikipedia) and tried to find a common
pattern. And this is, unfortunately, not easy (as everyone will know who
has spend a term abroad ;-).

> However, I do understand you want to ship something, and it's nice 
> that you want to document it openly. So, Information or Experimental 
> seems like a good fit here.

That would be fine with me. A don't know about James, though.

> powers. :) There are quite a few sections that seem to have a very
> low return to me. I think you need to cut, and cut a lot. I think the

You mean r:rank, right? Well, the purpose of r:scheme (and its child
elements) is to describe the ordered set from which r:rank's values a
picked. Think of it as a datatype definition geared specifically at
describing those sets of numbers commonly encountered in grading schemes.

>> A "Ranking Domain" is a uniquely identifiable logical set of
>> entries with associated numeric ranking values.
> 
>> A "Ranking Scheme" identifies specific rules on how to interpret
>> the numeric ranking values within one or more "Ranking Domains".
> 

James has made a change to that respect. The draft now stars an Overview
section instead of the more formal language above -- and it is still
shorter than the previous one. :-)

>> rankingScheme = element r:scheme { atomCommonAttributes, attribute
>> name { IRI }?, attribute label { text }?, attribute significance {
>> 'ascending' | 'descending' }?, ( value | range )* }
>> 
>> The "name" attribute provides a universally unique identifier for
>> the scheme in the form of an absolute IRI.
> 

Well, I am not sure what you mean here, but as for @domain you have to
realize that a single scheme can be used to rank entries within more
than one Ranking Domain (e.g.., within several feeds).

Changing @name to @id might cause confusion, since attributes called
"id" commonly contain NCNames, not IRIs. I suggest to James using an
r:id child element of r:scheme, instead, to mimic atom:id, but somehow
he doesn't like the idea. But maybe you can come up with a better name 
for @name (no pun intended).

>> "descending" indicates that the significance of the rank decreases
>> as the numeric ranking value increases.  A value of "ascending" 
>> indicates that the significance of the rank increases as the
>> numeric ranking value increases.  If not specified, the
>> significance is considered to be "ascending".
> 

I don't think it is the term "significance" that is confusing  but the
way the above paragraph is phrased. I could probably be simplified.

(IMHO, "significance" is a more precise term than "order", since the
latter refers to the order of *entries* as presented to the user,
whereas the former refers to the order of *rank values* within the
scheme/set.)

>> An Atom feed element MAY contain any number of r:scheme elements.
>> A feed MUST NOT contain more than one r:scheme element with the
>> same name.
> 

I don't understand the above. :-( Can you please clarify your objection.
Thanks.

>> The "scale" attribute on both the value and range elements
>> specifies the total number of decimal digits to the right of the
>> decimal indicator in the value of the numeric ranking value.  The
>> scale is
> 
> I don't understand this.
> 
>> expressed as a non-negative integer.  If not specified, the value
>> is considered to be zero.  Ranking Schemes that are based on
>> fractional numeric ranking values SHOULD specify a scale.  Numeric
>> ranking values that use a larger scale than defined for the scheme
>> MUST be rounded to the nearest in-scale value (e.g. with scale=2,
>> the rank 0.123 is rounded down to 0.12, the rank 0.125 is rounded
>> up to 0.13.)

I don't see the usefulness of @scale either. I probably need to argue
some more with James about it. ;-)

> ..
> This section is really, really dense. I have a hard time
> understanding any of it. Perhaps some Excel-like ASCII table
> illustrations would help.

I will try to prepare an alternative section on r:rank and r:value later
today and post it to atom-syntax to see whether it is easier to understand.

> is necessary. Is the idea that clients have to know that to edit?

Well, for one thing you do not want specify whether the significance of
a ranking is "ascending" or "descending" on each and every element.

And what r:value and r:range are supposed to provide is some kind of
datatype definition for r:rank's value, so that an application might for
example adjust its "Filter" GUI accordingly.

>> Ranking Domains group entries with attached numeric ranking values
>> to logical sets.  Ranking Domains are uniquely identified by IRIs.
> 

:-)

The notion of Ranking Domains is going to be much simplified in the next
draft.

> This seems like overkill.

Why? It is just a convenient shorthand that takes almost no time to
implement.

> Oh wait, is this the introduction of this term? It doesn't seem
> useful to me. I suggest text along the lines of "If there is no
> scheme specified, [explain default processing]." No terminology
> necessary.

Personally I find it easier to think about default data instead of
default processing; that's a "Show me your flowcharts [...]. Show me
your tables [...]" thing.

> You should also acknowledge verbatim copies of text from RFC4287.

Done

Best wishes,

Andreas Sewe

---

From: David Powell <[email-masked]>
Date: Fri, 5 May 2006 12:26:37 +0100

Friday, May 5, 2006, 4:05:15 AM, Tim Bray wrote:

> small lifespan in comparison

The issue isn't that an implementation is at fault. The issue is that
a implementation is not at fault, is behaving reasonably, and yet
still wouldn't be compatible with the extension.

As I said 12 months ago
<http://www.imc.org/atom-syntax/mail-archive/msg15795.html>:

| The problem with section 6 is that we define 3 different classes of
| non-Atom markup, but don't say why we've done that, or help authors to
| know which type they should choose when they write a document.
| [...]
| It doesn't really make sense we have thought out how to extend
| atom:feed, atom:entry, atom:author etc, but atom:link is a sub-RSS
| free-for-all.

Section 6 was received inadequate review. Perhaps someone can tell me
now, why there are three different classes of non-Atom markup?

Section 6 came about due to a clash between people who see Atom as an
XML document format like XHTML ([1] choice 1), and people who see Atom
as a serialisation of feed and entry concepts, that span multiple XML
documents ([1] choice 2). Section 6 satisfies neither party.

[1] http://www.mnot.net/blog/2004/05/12/on_infosets

The distinction between Simple and Structured extensions was a well
meaning, but misguided, effort to provide a lower bar for extension
support for implementations that would find it unfeasible to preserve
the full Infoset and xml:lang/xml:base context.

> crippling our expressiveness

"...and conservative in what you send".  That is the point here.

What percent of stateful feed stores do you think support all of
Atom's core elements?

How many handle xml:lang and xml:base correctly for core elements? -
less?

How many handle simple extensions? - less?

How many handle structured extensions, including ones that require that the xml:base
and xml:lang context is preserved? - less?

How many handle arbitrary attributes on any Atom element, and
arbitrary XML in atom:link? - less?

How many preserve the order of elements for any future extensions that
choose to make order significant? - less?

How many cope with extensions that follow our example of
"inheritance", and maintain feed extensions as they were at the time
of the document that the entry was last delivered with for the benefit
of "inheritable" feed extensions, whilst also maintaining an
association with the latest feed metadata for the benefit of "true"
feed extensions? - less?

How many preserve the namespace mappings for any future extensions
that choose to use QNames in content? - less?

How many preserve PIs and comments for any future extensions that make
use of them? - less?

Atom doesn't define any conformance levels for the preservation of
content and extensions, so extension designers are forced to consider
the consequences themselves.

If you're happy working with XML APIs over a set of polled feed
documents (together with their preserved URIs, Content-Locations,
entity headers and retrieval dates), then none of this matters.

If you see a benefit of providing a higher level abstraction over
feeds and entries, an OO API, an RDBMS schema, an APP implementation,
or any value-added feed processing service, then it is worth
considering the practicalities of such support and employing a bit of
conservatism.

-- 
Dave

---

From: "Robert Sayre" <[email-masked]>
Date: Fri, 5 May 2006 08:41:24 -0400

> describing those sets of numbers commonly encountered in grading schemes.

Why don't you call it that in the draft?

> for @name (no pun intended).

Ranking Domain. I'm still not sure what that means.

> I don't understand the above. :-( Can you please clarify your objection.

I don't see the interoperation problem the MUST NOT is preventing.

--

Robert Sayre

---

From: David Powell <[email-masked]>
Date: Fri, 5 May 2006 14:15:15 +0100

> there is, what else would that mean than that we did a shoddy

The RFC does a good job of saying what is and isn't a valid Atom
document. What is out of scope of the RFC though, is the behaviour of
processors that provide access to, store, or act as intermediaries for
Atom streams, wrt what elements and extensions are retained.

Not that all processors should behave the same, or that processors
that retain the most information are necessarily "the best" (ones that
retain less information are probably likely to offer more usable
interfaces), just that extension authors need to be mindful of typical
behaviours of processors, and vice versa. As the processing behaviour
is not defined (not even in APP), application of the robustness
principle is particularly relevant.

I started on a document describing some checklists for the
preservation of data required to meet several arbitrary conformance
levels - intended more as considerations for extension authors, than
for processor implementations.

-- 
Dave

---

From: "M. David Peterson" <[email-masked]>
Date: Fri, 5 May 2006 07:23:10 -0600

Hmmm... yeah, thats a good point.  The optimizations part wouldn't represent
this (e.g. thr:count -- although this doesn't reflect on the Atom spec) but
beyond that there wouldn't be much point.  You folks HAVE done a incredibly
complete job with the spec, so if there was interest it would only be
artificial.

Is an optimizations research area something that might be doable beyond the
notion of fixing or adding whats not already there, and instead focused on
things like thr:count where its nice to have, but not mandatory, yet a
consolidated effort would make sense?

On 5/4/06, A. Pagaltzis <[email-masked]> wrote:
> I don't know. So far during extension development discussions,
> At least, that's my impression; I don't know what others think,
> of course.
>
> Frankly, I would hope there won't be much interest – cause if

--
<M:D/>

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

---

From: "M. David Peterson" <[email-masked]>
Date: Fri, 5 May 2006 07:25:14 -0600

So kind of like a best practice doc?

--
<M:D/>

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