[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Fwd: I-D Action:draft-saintandre-atomlink-discuss-00.txt]
* Peter Saint-Andre <stpeter@xxxxxxxxxx> [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
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
• `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.
Aristotle Pagaltzis // <http://plasmasturm.org/>