[LinkLog] flaw in the link rel="related"

[Isofarro <yahoosyndication@xxxxxxxxxxxxxxxxxxxx>]

Hi there,

I think I've spotted a flaw in the current link-log specification / guidelines -
or I've missed something really obvious. It happens when there are related
links. For example, currently on Mark's linkblog is this entry:

<entry>
    <title>a byte of python</title>
    <link rel="alternate" type="text/html"
href="http://diveintomark.org/archives/blinks/2004/06/#b20040602144845"/>
    <issued>2004-06-02T14:48:45Z</issued>
    <created>2004-06-02T14:48:45Z</created>
    <modified>2004-06-02T14:48:45Z</modified>
	<id>tag:diveintomark.org,2004-06-02:/archives/blinks/20040602144845</id>
    <summary>python doesn't have a periodic table of operators</summary>
  <link rel="related" type="text/html"
href="http://www.smith-house.org/books/Others/byte_of_python_115.html"; title="a
byte of python"/>
  <link rel="related" type="text/html" href="http://www.python.g2swaroop.net/";
title="byte of python downloads"/>
</entry>


As I understand it, the link rel="alternate" is an alternate representation of
the current entry - which is a comment about a resource.

The resource itself is identified in the link rel="related". Links which are
related to this item are also listed with a link rel="related". How is the URI
being discussed to be identified when there are multiple links of
rel="related"?

My thoughts are that it would be the first link defined as rel="related", but
that would mean that the order of the links is significant. Currently our Atom
0.3 specification, for the entry element states: "Ordering of the element
children of atom:entry element MUST NOT be considered significant."

http://www.mnot.net/drafts/draft-nottingham-atom-format-02.html#rfc.section.4.13

As far as I can tell, there's a conflict.

If I have stumbled across a genuine problem, then I make the suggestion of using
rel="bookmark" for the URI being discussed, and keep using rel="related" for
related links.

I am happy to volunteer to do a Pace to resolve this particular issue, even if
another solution is the preferred option.

Thanks,
Mike