[Fwd: I-D Action:draft-saintandre-atomlink-discuss-00.txt]

[Peter Saint-Andre-2]

FYI.

-------- Original Message --------
From: Internet-Drafts@...
To: i-d-announce@...
Subject: I-D Action:draft-saintandre-atomlink-discuss-00.txt
Date: Tue, 27 May 2008 20:00:02 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

        Title           : Atom Link Relation: Discuss
        Author(s)       : P. Saint-Andre
        Filename        : draft-saintandre-atomlink-discuss-00.txt
        Pages           : 8
        Date            : 2008-05-27

This specification defines a link relation that enables an Atom
document to point to a venue for multi-party discussion of the
document or its primary topic.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-saintandre-atomlink-discuss-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

[James M Snell]

Bug: Section 4, "Notice that the entry contains three links of type
"relation" (which can be differentiated via the URI scheme, i.e., "xmpp"
^^^^^^^^^^
vs. "mailto" vs. http") and three links to HTTP resources (which can be
differentiated via the relation type, i.e., "discuss" vs. "related")."

Should be "... of type "discuss" ... "

- James

Peter Saint-Andre wrote:

> FYI.
>
> -------- Original Message --------
> From: Internet-Drafts@...
> To: i-d-announce@...
> Subject: I-D Action:draft-saintandre-atomlink-discuss-00.txt
> Date: Tue, 27 May 2008 20:00:02 -0700 (PDT)
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
> Title           : Atom Link Relation: Discuss
> Author(s)       : P. Saint-Andre
> Filename        : draft-saintandre-atomlink-discuss-00.txt
> Pages           : 8
> Date            : 2008-05-27
>
> This specification defines a link relation that enables an Atom
> document to point to a venue for multi-party discussion of the
> document or its primary topic.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-saintandre-atomlink-discuss-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>

[James M Snell]

Bug: Section 3, "...or following other people's comments (the "comments"
relation) rather..."

That should be the "replies" relation, not "comments"

- James

Peter Saint-Andre wrote:

> FYI.
>
> -------- Original Message --------
> From: Internet-Drafts@...
> To: i-d-announce@...
> Subject: I-D Action:draft-saintandre-atomlink-discuss-00.txt
> Date: Tue, 27 May 2008 20:00:02 -0700 (PDT)
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
> Title           : Atom Link Relation: Discuss
> Author(s)       : P. Saint-Andre
> Filename        : draft-saintandre-atomlink-discuss-00.txt
> Pages           : 8
> Date            : 2008-05-27
>
> This specification defines a link relation that enables an Atom
> document to point to a venue for multi-party discussion of the
> document or its primary topic.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-saintandre-atomlink-discuss-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>

[Aristotle Pagaltzis]

Hi Peter,

I still don’t know what sort of automatic processing of such
links a machine is expected to perform.

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

[Peter Saint-Andre-2]

On 05/28/2008 10:16 AM, Aristotle Pagaltzis wrote:

> I still don’t know what sort of automatic processing of such
> links a machine is expected to perform.

I still don't know why you expect a machine to perform automatic
processing of links based on the link relation. RFC 4287 states:

   The value of "rel" describes the meaning of the link,
   but does not impose any behavioral requirements on Atom
   Processors.

Last I checked on the status of artificial intelligence research,
machines such as Atom Processors were not very adept at ascribing or
understanding the meaning of links, or of anything else.

What kind of automatic processing do you expect a machine to perform for
links whose relation is alternate, license, payment, related, replies,
self, or any of the others registered with the IANA so far? Perhaps that
would help me understand what's missing.

Peter

--
Peter Saint-Andre
https://stpeter.im/

[Brian Smith-19]

Peter Saint-Andre wrote:
> What kind of automatic processing do you expect a machine to
> perform for links whose relation is[:]

> alternate

My feed reader follows the alternate link when I click the "see the web page for this entry" button.

> license,

I guess if you link to a well-known location for a license, or the application can somehow recognize the license, then you could categorize entries/feeds by license. This would allow you to set up a 100% legal spamblog by seeking out only Creative-Commons Sharalike content, for example.

> payment,

Useless, for now.

> related

Oddly, the default is "alternate" if no relation is given. So, you need "related" to mean "no other relation applies."

> replies

Links to a feed containing comments/replies to the current entry. My current feedreader doesn't do anything useful with this, but it easily could, and I wish it did.

> self

When a feed reader is passed a feed document from a web browser, it uses the "self" link to locate the feed's subscription URL.

Regards,
Brian

[James M Snell]

FWIW, there are readers that do handle this one automatically.  Liferea,
for instance, will automatically follow the link and display the comment
thread.

- James

Brian Smith wrote:
> [snip]
>> replies
>
> Links to a feed containing comments/replies to the current entry. My current feedreader doesn't do anything useful with this, but it easily could, and I wish it did.
> [snip]

[Peter Saint-Andre-2]

On 05/28/2008 11:51 AM, James M Snell wrote:
> FWIW, there are readers that do handle this one automatically.  Liferea,
> for instance, will automatically follow the link and display the comment
> thread.

I don't know how much intelligence we expect an Atom Processor to have,
but if it is aware of the discussion technology referred to by a link
then it could gather and display relevant meta-information about the
discussion venue (such as the number of participants in an IRC channel
or XMPP groupchat room), fetch the last few threads or the messages in
the current thread from a newsgroup or webforum and display a summary of
that information (e.g., if there is a specific thread about the Atom
feed or entry referred to in the link), etc.

Peter

--
Peter Saint-Andre
https://stpeter.im/

[Aristotle Pagaltzis]

* Peter Saint-Andre <stpeter@...> [2008-05-28 19:00]:
> I still don't know why you expect a machine to perform
> automatic processing of links based on the link relation.

Because there is no other reason to tell programs that one link
is of one type vs another.

The majority of links on the web are just `<a href>` with absent
`rel` attribute. But there are also many `<img src>` links. Why
do we need two types of link? Because we want browsers to be able
to load and show images automatically. To do so, the browser must
be able to tell them apart.

> RFC 4287 states:
>
>    The value of "rel" describes the meaning of the link,
>    but does not impose any behavioral requirements on Atom
>    Processors.

Correct. This is equivalent to saying that just because there is
an `<img>` tag in an HTML document does not at all *obligate* the
browser to load that image. If the user has turned image loading
off, and the browser therefore skips requesting that URI, it does
not suddenly fail to comply with the HTML spec. Likewise, all of
the links in an Atom document are there for the Atom processor to
do something with if it so chooses, with no implied obligation to
act on any of them in any way.

> Last I checked on the status of artificial intelligence
> research, machines such as Atom Processors were not very adept
> at ascribing or understanding the meaning of links, or of
> anything else.

What does that have to do with anything?

> What kind of automatic processing do you expect a machine to
> perform for links whose relation is alternate, license,
> payment, related, replies, self, or any of the others
> registered with the IANA so far?

• `alternate`: The one link that is used as the canonical
  location of the entry. F.ex. in a river-of-news view, it is
  used as the link target of entry headers, or in a desktop
  three-pane aggregator, is the link you go to by doubleclicking
  a row in the list-of-entries pane.

• `license`: At the time being, the main purpose of this relation
  is to denote that this link should *not* be shown to the user.
  Not much more is actually done with it, to my knowledge,
  although if software came with a list of license URIs built and
  they were in common use, some interesting possibilities might
  arise.

• `payment`: Never heard of this one before. I don’t know how
  it’s used or if it’s any good.

• `related`: Different from all other link relations in that this
  one specifically signifies that the link is for human
  consumption, not for automated processing. This is the
  catch-all, default, fallback relation to be used for all links
  that aren’t automatically processed.

• `replies`: Aggregators can automatically retrieve a feed from
  this link to follow the conversation related to the entry that
  the link belongs to.

• `self`: When subscribing to the feed in which this link is
  found among its metadata, use this URI (even if you retrieved
  it from some other URI).

As you see, in all these cases (except `payment` which I know
nothing about) there is some difference in the way in which a
computer program handles the link in question, and in order to
let the machine know which links you expect to be treated in
this particular fashion, you need a `rel` value to denote them.

So far, all we know about how you expect programs to process
`discuss` links is to show them to the user – which is exactly
the same as what `related` means. Remember that the term
`related` is chosen by analogy with English (because we have to
give it some name, and names are human concepts), but it’s not
the English meaning that matters, it’s the processing model.

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

[James Holderness]

Peter Saint-Andre wrote:
> I don't know how much intelligence we expect an Atom Processor to have,
> but if it is aware of the discussion technology referred to by a link
> then it could gather and display relevant meta-information about the
> discussion venue (such as the number of participants in an IRC channel
> or XMPP groupchat room), fetch the last few threads or the messages in
> the current thread from a newsgroup or webforum and display a summary of
> that information (e.g., if there is a specific thread about the Atom
> feed or entry referred to in the link), etc.

If your Atom processor were capable of doing those things, why would it not
want to do them on related links or alternate links? Why is it appropriate
to display the number of participants in an IRC channel if you're linking
via a discuss link, but it's not appropriate if you're linking for some
other reason?

I'm strongly opposed to any link rel proposal that has no potential client
implementation, or where the implementation would be the same as existing
link relationships.

Regards
James

[Peter Saint-Andre-2]

On 05/28/2008 4:02 PM, James Holderness wrote:

>
> Peter Saint-Andre wrote:
>> I don't know how much intelligence we expect an Atom Processor to have,
>> but if it is aware of the discussion technology referred to by a link
>> then it could gather and display relevant meta-information about the
>> discussion venue (such as the number of participants in an IRC channel
>> or XMPP groupchat room), fetch the last few threads or the messages in
>> the current thread from a newsgroup or webforum and display a summary of
>> that information (e.g., if there is a specific thread about the Atom
>> feed or entry referred to in the link), etc.
>
> If your Atom processor were capable of doing those things, why would it
> not want to do them on related links or alternate links?

We've been down this path before. The "related" relation is void for
vagueness, since *everything* is related, otherwise why are you linking?
If someone can provide a much better definition of the "related"
relation then I'm open to retracting the idea of a "discuss" relation,
but the description (I don't think it can even be called a definition)
in RFC 4287 is uselessly circular, to wit:

   The value "related" signifies that the IRI in the value of the
   href attribute identifies a resource related to the resource
   described by the containing element.

"It's related because it's related." Thanks for the tautology.

> Why is it
> appropriate to display the number of participants in an IRC channel if
> you're linking via a discuss link, but it's not appropriate if you're
> linking for some other reason?

My point is that there is no true *reason* underlying the "related"
relation and that the other relations are not appropriate for linking to
a multi-party discussion venue where you can actively engage in an
interactive conversation with other people as opposed to passively
consuming a comments feed, statically finding an alternative location
for the main feed, etc.

Let me put it this way. On each IETF Working Group page there is a link
to the discussion venue for the WG (traditionally an email discussion
list just like this one). You follow that link if you don't just want to
find background information ("related"?) or read I-Ds and RFCs, but
instead want to join the conversation about the technology under
development. Those links are there for a reason, namely, because an
interactive discussion provides an entirely different kind of experience
from reading an I-Ds or RFCs. To paraphrase the old Palmolive
advertisements: "you're soaking in it"! I don't see why people on this
discussion list have such a hard time understanding that a multi-party
conversation provides a different kind of experience, since you've been
soaking in conversation for years now.

> I'm strongly opposed to any link rel proposal that has no potential
> client implementation, or where the implementation would be the same as
> existing link relationships.

I don't think it's the same at all, but I seem to be beating my head
against the wall attempting to explain why. Everyone I've talked to in
the social networking and real-time communication spaces gets the
concept of rel='discuss' immediately, but folks here just don't.
Therefore I will attempt to socialize the idea in other venues (e.g.,
some of the RAI lists) and see what folks there think.

Peter

--
Peter Saint-Andre
https://stpeter.im/

[Brian Smith-19]

Peter Saint-Andre wrote:

> On 05/28/2008 4:02 PM, James Holderness wrote:
> >
> > Peter Saint-Andre wrote:
> >> I don't know how much intelligence we expect an Atom
> >> Processor to have, but if it is aware of the
> >> discussion technology referred to by a link then it
> >> could gather and display relevant meta-information
> >> about the discussion venue (such as the number of
> >> participants in an IRC channel or XMPP groupchat
> >> room), fetch the last few threads or the messages in
> >> the current thread from a newsgroup or webforum and
> >> display a summary of that information (e.g., if
> >> there is a specific thread about the Atom
> >> feed or entry referred to in the link), etc.

> > If your Atom processor were capable of doing those things,
> > why would it not want to do them on related links or
> > alternate links?
>
> We've been down this path before. The "related" relation is void for
> vagueness, since *everything* is related, otherwise why are
> you linking?

I agree. If you require a specific kind of processing then "related" is not appropriate. Especially, you cannot always use the scheme of the IRI to decide what action to perform. For example, a xmpp:// link could be a link to a discussion or a link to an Atom-over-XMPP push subscription service. AFAICT, the only way to distinguish between the two would be to use different link relations for each usage.

> If someone can provide a much better definition of the "related"
> relation then I'm open to retracting the idea of a "discuss" relation,
> but the description (I don't think it can even be called a definition)
> in RFC 4287 is uselessly circular, to wit:
>
>    The value "related" signifies that the IRI in the value of the
>    href attribute identifies a resource related to the resource
>    described by the containing element.
>
> "It's related because it's related." Thanks for the tautology.

"related" should be used when you need to store a link for some reason and you don't care if/how it is exposed to any users along the way. Basically, rel="related" should almost never be used. If you need the UA to display some links to the user then you should put those links in the atom:content using (X)HTML markup to guarentee (as much as possible) that they show up (since not all Uas expose "related" links). If you don't want the UA to display the link then you should use something other than rel="related" because some UA's will expose all "related" links.

> > I'm strongly opposed to any link rel proposal that has no potential
> > client implementation, or where the implementation would be
> > the same as existing link relationships.
>
> I don't think it's the same at all, but I seem to be beating my head
> against the wall attempting to explain why. Everyone I've talked to in
> the social networking and real-time communication spaces gets the
> concept of rel='discuss' immediately, but folks here just don't.
> Therefore I will attempt to socialize the idea in other venues (e.g.,
> some of the RAI lists) and see what folks there think.

Peter, are clients supporting rel='discuss' already? It doesn't make sense to standardize something that nobody is doing. I say just go ahead and implement it and don't worry about the registration right now. Or, use something like rel="http://schema.briansmith.org/link/discuss" instead of rel="discuss"? Then you can avoid the whole issue by avoiding the registration process completely.

Regards,
Brian

[James Holderness]

Brian Smith wrote:

> Peter Saint-Andre wrote:
> > On 05/28/2008 4:02 PM, James Holderness wrote:
> > > If your Atom processor were capable of doing those things,
> > > why would it not want to do them on related links or
> > > alternate links?
> >
> > We've been down this path before. The "related" relation is void for
> > vagueness, since *everything* is related, otherwise why are
> > you linking?
>
> I agree. If you require a specific kind of processing then "related"
> is not appropriate.

Except a "discuss" link doesn't require a specific kind of processing - at
least none that has been disclosed so far. If it did, I wouldn't have a
problem with it.

> For example, a xmpp:// link could be a link to a discussion or a link
> to an Atom-over-XMPP push subscription service. AFAICT, the only way
> to distinguish between the two would be to use different link
> relations for each usage.

And an http link could be a link to a porn site or a link to a news site,
but without a "porn" link relationship there would no way to distinguish
between the two. We really need a whole lot more of these: "news",
"shopping", "sport", videos". We should define link relationships for every
possible category of web site.

Obviously that is ridiculous. Yes, we can't tell the difference, but why
should we care? Why does a client *need* to be able to distinguish between
links to discussions and links to anything else? Human readers obviously
care where something is linking, but that's why we have the title attribute.

> "related" should be used when you need to store a link for some reason
> and you don't care if/how it is exposed to any users along the way.

That implies that you *do* care how "discuss" links are exposed to users.
Please let me know *specifically* what you had in mind. I'm not asking for
REQUIRED behaviour - just your idea of what a perfect client *should* do.
Also, please explain why a client *shouldn't* perform the same processing on
other link types, such as "related" or "alternate".

> Peter, are clients supporting rel='discuss' already?

Please do tell us if that is the case. It would make this dicussion so much
easier if you could provide real examples of clients that are doing
something useful with these links.

As a feed publisher, if I wanted to link to an IRC channel, news forum or
mailing list where people were actively discussing a post, I would want the
readers of my feed to *see* that link and be able to click on it and join
the discussion. Right now I can get that functionality in a number of feed
readers using a "related" link. If I were to change my link to use
"discuss", it would suddenly become invisible. My feed would become
significantly less functional.

So why are you trying to convince people that this is a good idea? I'm
assuming you're not deliberately trying to make their feeds less functional.
So what is the great gain they'll get from using a "discuss" link that makes
this loss of functionality worthwhile? Where are the clients that are
supporting (or planning to support) "dicuss" links in some incredible way
that makes this all worthwhile?

Regards
James

[Peter Saint-Andre-2]

On 05/29/2008 2:27 PM, James Holderness wrote:

>
> Brian Smith wrote:
>> Peter Saint-Andre wrote:
>> > On 05/28/2008 4:02 PM, James Holderness wrote:
>> > > If your Atom processor were capable of doing those things,
>> > > why would it not want to do them on related links or
>> > > alternate links?
>> >
>> > We've been down this path before. The "related" relation is void for
>> > vagueness, since *everything* is related, otherwise why are
>> > you linking?
>>
>> I agree. If you require a specific kind of processing then "related"
>> is not appropriate.
>
> Except a "discuss" link doesn't require a specific kind of processing -
> at least none that has been disclosed so far. If it did, I wouldn't have
> a problem with it.
>
>> For example, a xmpp:// link could be a link to a discussion or a link
>> to an Atom-over-XMPP push subscription service. AFAICT, the only way
>> to distinguish between the two would be to use different link
>> relations for each usage.
>
> And an http link could be a link to a porn site or a link to a news
> site, but without a "porn" link relationship there would no way to
> distinguish between the two. We really need a whole lot more of these:
> "news", "shopping", "sport", videos". We should define link
> relationships for every possible category of web site.

Is the address space of link relations something that we want to
deliberately restrict? Why not let a thousand flowers bloom?

> Obviously that is ridiculous.

Nothing is obvious.

I bet some folks think that a link relation of "shopping" would be far
from ridiculous (link to the iTunes page where you can buy the song or
whatever). But I think that the proof of whether something makes sense
is experimentation out in the marketplace of ideas and in userspace.

> Yes, we can't tell the difference, but why
> should we care? Why does a client *need* to be able to distinguish
> between links to discussions and links to anything else?

Did I ever say a client MUST distinguish a "related" link from a
"discuss" link? No, I said that this might be useful. Whether that hunch
proves out depends on implementation and deployment experience.

> Human readers
> obviously care where something is linking, but that's why we have the
> title attribute.

You mean the title attribute of the <link/> element? I wonder how well
that would scale with regard to localization...

>> "related" should be used when you need to store a link for some reason
>> and you don't care if/how it is exposed to any users along the way.
>
> That implies that you *do* care how "discuss" links are exposed to
> users.

You bet I do. Do you think I go through these head-banging
standardization efforts for the sheer fun of it? ;-)

> Please let me know *specifically* what you had in mind. I'm not
> asking for REQUIRED behaviour - just your idea of what a perfect client
> *should* do.

I'll make that clearer in the next version of the I-D.

> Also, please explain why a client *shouldn't* perform the
> same processing on other link types, such as "related" or "alternate".

As I've said, "related" is void for vagueness and IMHO meaningless. But
if people in the real world are ascribing meaning to it (not captured in
the description from RFC 4287) then that's great. However, if that's so
then I wish someone would define it properly.

And a chatroom or email list or newsgroup where you can discuss an entry
does not fit under the "alternate" umbrella in any scenario I can think of.

>> Peter, are clients supporting rel='discuss' already?
>
> Please do tell us if that is the case. It would make this dicussion so
> much easier if you could provide real examples of clients that are doing
> something useful with these links.

No they aren't because I'm trying to do the right thing by defining how
it's supposed to work through standardization.

> As a feed publisher, if I wanted to link to an IRC channel, news forum
> or mailing list where people were actively discussing a post, I would
> want the readers of my feed to *see* that link and be able to click on
> it and join the discussion. Right now I can get that functionality in a
> number of feed readers using a "related" link. If I were to change my
> link to use "discuss", it would suddenly become invisible. My feed would
> become significantly less functional.

So why is there any link type except related? Every time someone defines
a new link relation (oh, say "edit" or "next") then by your theory we
are losing functionality.

> So why are you trying to convince people that this is a good idea? I'm
> assuming you're not deliberately trying to make their feeds less
> functional. So what is the great gain they'll get from using a "discuss"
> link that makes this loss of functionality worthwhile?

I don't see any loss of functionality, instead I see more granularity in
what is presented to the user.

> Where are the
> clients that are supporting (or planning to support) "dicuss" links in
> some incredible way that makes this all worthwhile?

I have not socialized any of these concepts among Atom client authors.
Perhaps it would have been more productive to start there than on this
list, but since this is the list for Atom syntax I figured it was a good
place to start. If that assumption is false, feel free to point me to a
more appropriate venue for discussing this topic.

Peter

--
Peter Saint-Andre
https://stpeter.im/

[Brian Smith-19]

James Holderness wrote:

> Obviously that is ridiculous. Yes, we can't tell the
> difference, but why should we care? Why does a client
> *need* to be able to distinguish between links to
> discussions and links to anything else? Human readers
> obviously care where something is linking, but that's
> why we have the title attribute.

If you have a feedreader that is capable of discovering comments for a given entry and it can display those comments (threaded) alongside the entry, then it seems reasonable to take that a step further and provide a means for the feedreader to add a new reply. It needs to be able to enable/disable its "reply" interface for each entry based on whether or not it can find a supported means of replying. Presumably that is what atom:link/@rel='discuss' is supposed to do.

Right now, you can look for a rel='replies' link, retrieve the replies feed, and search for an app:collection element that indicates the feed is an AtomPub collection feed. If so, then you could enable the reply feature and try submitting the reply via an AtomPub POST. Maybe something similar can be done with rel='replies' with XMPP? I don't know; I've never done anything with XMPP. Even if that is the case, the extra requests necessary for this kind of discovery might be unacceptable; a "reply" button should be enabled/disabled instantaneously when the entry is selected. For that reason, some indication within the entry of the possibility of replying is probably necessary. I guess that is what rel="discuss" is supposed to be for. If so, I think it should be mixed in with a specification of the entire discussion mechanism: how discussions are discovered, how exactly to reply, how to authenticate, how to deal with CAPTCHAs, etc.

> As a feed publisher, if I wanted to link to an IRC channel,
> news forum or mailing list where people were actively
> discussing a post, I would want the readers of my feed to
> *see* that link and be able to click on it and join the
> discussion. Right now I can get that functionality in a
> number of feed readers using a "related" link. If I were
> to change my link to use "discuss", it would suddenly
> become invisible. My feed would become significantly
> less functional.

You can have the same link provided using multiple relations.

A feed reader that doesn't refuses to show a link just because the link has a relation it doesn't understand sounds broken to me. If the feed reader is going to expose related links, it would be better off exposing all the links except the ones that it knows are not useful to the end-user.

A lot of feed readers (probably the vast majority) don't expose "related" links. In fact, I've tried a few feed readers and I've never used one that exposed the "related" links in any usable way to me. You have to put them in the atom:content as (X)HTML links if you want them to be accessible to people.

Regards,
Brian

[Eric Scheid]

On 30/5/08 8:19 AM, "Peter Saint-Andre" <stpeter@...> wrote:

> As I've said, "related" is void for vagueness and IMHO meaningless.

@rel='related' is more like zero - it at once means nothing and has no
value, yet is incredibly important. Similarly so for alt="" on images.

It is mu.

What link relation would you use if the related resource is not an alternate
representation, nor describes the service parameters, nor is the license,
nor is the feed source, nor any other known @rel value?

e.