Subject: PaceReplaceLinkElement: Is link-ness relevant?

From: Tim Bray <[email-masked]>
Date: Fri, 16 Jul 2004 12:47:57 -0700

I'm sure there must be some good reason why it's considered a good 
thing to be able to spot that an element is a link to something, even 
if you have no idea what the semantics of that link are.  I assume 
there must be some essential thing you can do given that knowledge.  
But I just went and poked around the Paces and I can't find it.  Could 
someone please provide some motivation or some use cases?  Because 
unless there's a good strong motivation, I don't understand why we're 
even having this discussion. -Tim

---

From: Sam Ruby <[email-masked]>
Date: Fri, 16 Jul 2004 17:11:31 -0400

Tim Bray wrote:
> 
> I'm sure there must be some good reason why it's considered a good thing 
> to be able to spot that an element is a link to something, even if you 
> have no idea what the semantics of that link are.  I assume there must 
> be some essential thing you can do given that knowledge.  But I just 
> went and poked around the Paces and I can't find it.  Could someone 
> please provide some motivation or some use cases?  Because unless 
> there's a good strong motivation, I don't understand why we're even 
> having this discussion. -Tim

It took me a while to dig this up:

http://www.intertwingly.net/wiki/pie/ExtensibilityFramework

- Sam Ruby

---

From: Antone Roundy <[email-masked]>
Date: Fri, 16 Jul 2004 17:28:29 -0600

> even having this discussion. -Tim
A non-Atom example: If you put the following into the head of an HTML 
document and load it in Mozilla with the Site Navigation Bar active 
(look under View >> Show/Hide >> Site Navigation Bar), a "More" menu 
will show up with the link in it.

<link rel="MyLinkType" title="This links to something" 
href="http://www.example.org/">

Any @rel value that Mozilla doesn't understand will get its own submenu 
with any links of that type showing up in it.

---

From: Graham <[email-masked]>
Date: Fri, 16 Jul 2004 20:36:27 -0400

On 16 Jul 2004, at 7:28 pm, Antone Roundy wrote:

> Any @rel value that Mozilla doesn't understand will get its own 
> submenu with any links of that type showing up in it.

As an aggregator developer, I'd like to declare I have no plans (or 
desires) to do anything at all with unrecognised Link constructs, and 
thus no desire to be able to pick them out easily.

Graham

---

From: Ken MacLeod <[email-masked]>
Date: 16 Jul 2004 19:56:22 -0500

Sam Ruby <[email-masked]> writes:

> > thing to be able to spot that an element is a link to something,
> > even if you have no idea what the semantics of that link are.  I
> > assume there must be some essential thing you can do given that
> > knowledge.  But I just went and poked around the Paces and I can't
> > find it.  Could someone please provide some motivation or some use
> > cases?  Because unless there's a good strong motivation, I don't
> > understand why we're even having this discussion. -Tim
> 

ExtensibilityFramework uses @ref as a foreign key reference.

Another example was in,

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

where @ref (coincidentally) was used to mean a link to an element that
needs to be copied to downstream feeds.

Implementations know the processing behavior of the link by the
attribute used to reference the link, the "relation type" in
LinkReferences.

Being able to scan for links of a certain relation type gives an
implementation an ability to process them as a group.

@href in SkunkLink[1] is like <link> in HTML, and browsers and Atom
clients know to make those available in a menu for the user.

One of the key differences in the proposed link markup styles is
whether to make the element name the relation name or the relation
type.

  * If the element name is the relation type, then the relation name
    goes in an @rel attribute and we have do spec extensibility for
    the value of that attribute, and the URI goes in @href.

  * If the element name is the relation name, then the relation type
    is given as the attribute name, and the value of that attribute is
    the link.

An interesting issue to consider with links is where entries and feeds
link to other entries and feeds.  It makes the most sense for these
links to be made to the <id> URI, which we've strongly emphasized
should not have a (or be the) primary access mechanism for the
entry/feed.  "parent" and "in-reply-to", for example.  This means that
these links should have two URI properties, one linking the ID and one
linking a last-well-known URI location for the Atom version of the
entry:

  <in-reply-to uri="tag:example.com,2004:001"
               location="http://example.com/001.atom"/>

or, from PaceServiceElement,

  <service name="in-reply-to"
           href="tag:example.com,2004:001"
           location="http://example.com/001.atom"/>

  -- Ken

[1] http://dubinko.info/writing/skunklink/

---

From: Dare Obasanjo <[email-masked]>
Date: Fri, 16 Jul 2004 19:31:44 -0700 (PDT)

> thus no desire to be able to pick them out easily.

+1 

Same here. Currently the link construct is a hack. If
the link element has a fixed list of rel values then
it is just a hack around having elements with distinct
names and make Atom appear simpler than it is to
newbies 'viewing source' on a feed. This hack leads to
a style of naming elements that is un-idiomatic for
XML vocabularies. 

If link has an open list of @rel values, it is pretty
useless for aggregators to do anything with it. Just
in the various Atom Paces and spec drafts there are
links that mean (i) this is a link to a human readable
document (ii) this is a link to code for processing
the content of a sibling element of this link element
(iii) this is a link to an image file which is the
logo for the producer of this feed (iv)here is an
image file that is an icon that can be used to
represent this feed in applications that display feeds
in a tree view (v) here is a URI that one can POST
Atom entries as a response to the content of one the
siblings of this link element (vi) here is a link to a
syndication feed containing comments in response to
the content of one of the siblings of the link element

Each one of the above scenarios will require a unique
code path if implemented in RSS Bandit. Besides the
initial code that grabs all elements named <link>
there will be no similarity to the how these elements
will be processed or how they will be presented to the
end user. 

Thus there is no generic code for processing links.
Link tag extensibility in Atom is an oxymoron. 

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

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

---

From: Sam Ruby <[email-masked]>
Date: Fri, 16 Jul 2004 22:48:58 -0400

> Link tag extensibility in Atom is an oxymoron. 

A real life example:

   http://intertwingly.net/slides/2003/xmlconf/45.html

For the benefit of others: this slide was added to my presentation based 
on a question from Dare the day before I did my presentation.

Much of the current discussion is focusing on "rel" as if it is the most 
important attribute, but at times simply having a recognized media type, 
a title, and an href is all you need to present a relevant choice to a user.

- Sam Ruby

---

From: Dare Obasanjo <[email-masked]>
Date: Fri, 16 Jul 2004 19:58:37 -0700 (PDT)

> relevant choice to a user.

It isn't. Your argument is that you can show all the
links as hyperlinks to a user. My point is that even
looking at the list of link elements in Atom today,
less than half of them would be useful if they were
just shown to the user as hyperlinks. You can always
come up with one example that proves your point. I can
always come up with a counter example (e.g.
service.post).  

How about countering my statement and those of Graham
that there is simply no consistent way to process the
various link elements that exist in Atom today let
alone processing arbitrary link elements that could be
produced by any third party. 

=====

---

From: Ken MacLeod <[email-masked]>
Date: 16 Jul 2004 22:04:13 -0500

Graham <[email-masked]> writes:

> desires) to do anything at all with unrecognised Link constructs,
> and thus no desire to be able to pick them out easily.

One suggestion for links is classifying links that are "intended
primarily for presentation to a human user", distinct from other types
of links and irrespective of the link relation name (@rel or element
name).

Does that make a difference?

  -- Ken

---

From: Eric Scheid <[email-masked]>
Date: Sat, 17 Jul 2004 13:10:30 +1000

> href="http://www.example.org/">

to come full circle, an atom-related example ... if you put this into HTML
you get something quite handy. you don't need to lobby w3c to include a new
tag in the next version of html, you don't need to use name spaces, you just
use the existing functionality ...

    <link @rel="alternate" type="application/atom+xml" href="...">

e.

---

From: Sam Ruby <[email-masked]>
Date: Fri, 16 Jul 2004 23:12:23 -0400

Dare Obasanjo wrote:

>>>Thus there is no generic code for processing
>>
>>links.
>>

That was not my argument.  My argument was that an aggregator could 
chose to filter links based on media type instead of rel.

> produced by any third party. 

On one hand, there is a pace to separate out service elements.

On the other hand, the service elements are designed to exactly match 
the syntax used to place this exact same information inside your HTML 
pages for service discovery.

- Sam Ruby

---

From: Dare Obasanjo <[email-masked]>
Date: Fri, 16 Jul 2004 20:32:01 -0700 (PDT)

> chose to filter links based on media type instead of

http://intertwingly.net/wiki/pie/LinkTagMeaning

That is a list of Atom link tags and media types. I
notice that even when you group link tags by media
types, you still can't treat them consistently. 

If the link tag is going to be an extensibility point
then formally defined link types should be created so
links that share similar semantics can be processed
consistently by aggregators. 

Right now all I've seen suggested are a bunch of hacks
that are infeasible for aggregator authors to program
against with any  kind of consistency. 

> pages for service discovery.

Ah, yes. The false goal rears its ugly head. Why is it
important that elements in an Atom feed mimic the look
of HTML elements? Is there an expectation that
fragments of Atom feeds will appear in HTML pages? 

=====

__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

---

From: Graham <[email-masked]>
Date: Fri, 16 Jul 2004 23:37:54 -0400

On 16 Jul 2004, at 10:48 pm, Sam Ruby wrote:

> For the benefit of others: this slide was added to my presentation 
> based on a question from Dare the day before I did my presentation.
>
> Much of the current discussion is focusing on "rel" as if it is the 
> most important attribute, but at times simply having a recognized 
> media type, a title, and an href is all you need to present a relevant 
> choice to a user.

But what *is* the relationship here? alternate? related? via? What? I 
cannot present this usefully without knowing what it's for.

> of links and irrespective of the link relation name (@rel or element

It doesn't do anything for me, sorry. Like I said, even if I know a 
link is "clickable", I still want to make sure I'm doing the right 
thing with it. I'd still only bother with known Link constructs. The 
syndication world is small enough that any extension that comes up I 
can figure out what the best thing to do with it is myself, rather than 
have copies of Shrook in the wild presenting nonsense.

Graham

---

From: Eric Scheid <[email-masked]>
Date: Sat, 17 Jul 2004 13:10:09 +1000

> produced by any third party.

what is your position regarding PaceLinkPurpose, which addresses this
specific issue of semantics of use?

e.

---

From: Ken MacLeod <[email-masked]>
Date: 16 Jul 2004 23:10:21 -0500

Eric Scheid <[email-masked]> writes:

> > A non-Atom example: If you put the following into the head of an
> > HTML document and load it in Mozilla with the Site Navigation Bar
> > active (look under View >> Show/Hide >> Site Navigation Bar), a
> > "More" menu will show up with the link in it.
> > 
> to come full circle, an atom-related example ... if you put this
> into HTML you get something quite handy. you don't need to lobby w3c
> to include a new tag in the next version of html, you don't need to
> use name spaces, you just use the existing functionality ...
> 

The problem with this is @rel name collision, the values are a flat
namespace.  HTML document authors don't make much use of <link>, but
micro-content authors (like Atom authors) are really getting into
links in a serious way.  Name collision is inevitable.

There is no difference of difficulty or specification between making
up your own fully-qualified @rel value or making a new element, you're
still using XML Namespaces.

I think we can sum up the debate by saying whether we're going to
allow qnames in content or not.

QNames in content have "curb appeal" because it reuses elements for
common relation types, but elements have "implementation appeal"
because the implementor doesn't have to reimplement a function of the
XML parser.

I believe the "curb appeal", however, is waning.  Just as users have
come to expect new elements for new metadata fields, they are coming
to expect new elements for new link fields.  Our own <id> and <url>
are examples of that.

  -- Ken

---

From: Antone Roundy <[email-masked]>
Date: Fri, 16 Jul 2004 22:42:00 -0600

> allow qnames in content or not.
Yeah, we'd definitely have to come up with some way to avoid name 
collisions, but there are various ways we might do that: having qnames 
in @rel; specifying that anything with @href MUST be a Link Construct; 
specifying that anything whose name begins with "link-" MUST be a Link 
Construct (eg. <foo:link-bar title="This links to something" href="..." 
/>); making an extension namespace to identify Link Constructs 
(<foo:bar ex:href="..." ... />); etc.

---

From: Ken MacLeod <[email-masked]>
Date: 17 Jul 2004 00:25:57 -0500

Antone Roundy <[email-masked]> writes:

> collisions, but there are various ways we might do that: having
> qnames in @rel; specifying that anything with @href MUST be a Link
> Construct; specifying that anything whose name begins with "link-"
> MUST be a Link Construct (eg. <foo:link-bar title="This links to
> something" href="..." />); making an extension namespace to identify
> Link Constructs (<foo:bar ex:href="..." ... />); etc.

Between a localname pattern (link-*) and link relation type attributes
(@href, @ex:href), I'd choose link relation type attributes.

Two issues with link-* localnames:

Most importantly, it doesn't solve the naming issue, only reduces it.
There'd be some non-Atom vocabulary out there defining elements with
link-* in their localnames, then somebody else would want to embed
that content into an Atom document.

Less importantly, I don't think it's common for libraries to support
searching for elements based on a localname name pattern.

  -- Ken

---

From: Eric Scheid <[email-masked]>
Date: Sat, 17 Jul 2004 15:42:52 +1000

> thus no desire to be able to pick them out easily.

but do you have plans or desires to do anything with link constructs you
*do* recognise?

If you are going to ignore all links, unrecognised or no, then your
objection is moot. If you are going to do something with certain kinds of
links, then what's stopping you from just ignoring the ones you don't
recognise?

e.

---

From: Eric Scheid <[email-masked]>
Date: Sat, 17 Jul 2004 15:52:59 +1000

> that content into an Atom document.

well noted.

the same goes for atom:href

e.

---

From: Eric Scheid <[email-masked]>
Date: Sat, 17 Jul 2004 16:23:33 +1000

> the same goes for atom:href

doh!

which would be written as 'href' because of default namespace contortions.

e.

---

From: Ken MacLeod <[email-masked]>
Date: 17 Jul 2004 01:32:17 -0500

Graham <[email-masked]> writes:

> [...] even if I know a link is "clickable", I still want to make
> sure I'm doing the right thing with it. I'd still only bother with
> known Link constructs. The syndication world is small enough that
> any extension that comes up I can figure out what the best thing to
> do with it is myself, rather than have copies of Shrook in the wild
> presenting nonsense.

If I read this right, you're not against having more refined[1] or
more precise link relation names (@rel or in element name) or whether
those relation names are grouped into relation types (clickable,
service), you're only going to present the relations you know of
to-date, correct?

I don't see any problems with that approach.

  -- Ken

[1] "Refined" is used in Dublin Core to mean terms that are more
precise than the terms they are derived from.  It's also used from a
"schema" or "subclassing" perspective, where you're allowed to use a
more precise term in situations where you'd use the less precise term.

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 17 Jul 2004 13:01:24 +0100

> a title, and an href is all you need to present a relevant choice to a 

But not all the time. And @rel /is/ the most important attribute in 
this case, as it is least well defined, most open to abuse, most 
likely to hurt interopration in a free for all scenario. Even in a 
closed scenario feedback on the list we have suggests no-one is 
going to want or be able to process them uniformly - they're clearly 
disjoint. And no, the filter by media type argument isn't sufficient 
to partition out a clean subset of links. I suugest introducing 
co-occurence constraints like this is not addressing the problem.

cheers
Bill

---

From: Sam Ruby <[email-masked]>
Date: Sat, 17 Jul 2004 08:10:23 -0400

> which would be written as 'href' because of default namespace contortions.

Just a point of clarification, from an XML point of view, "atom:href" 
and "href" are always considered distinct attributes, independent of the 
value of the default namespace in effect on this element.

 From http://www.w3.org/TR/REC-xml-names/#defaulting:

     Note that default namespaces do not apply directly to attributes.

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Sat, 17 Jul 2004 11:28:11 -0400

On 7/16/04 10:31 PM, "Dare Obasanjo" <[email-masked]> wrote:

> Same here. Currently the link construct is a hack.

I'm not going to argue with you guys if you disagree, but wouldn't taking
all types of link elements into account help for PageRank-type algorithms? I
use RSS Bandit to see what it's like subscribing to lots of feeds; way more
than I can reasonably read. It would be nice for aggregators to present me
with "URIs that everyone is talking about".

For example, I subscribe to Slashdot, The Register, CNET, etc. I rarely read
them, but it'd be nice to know if they were all talking about the same
thing.

Perhaps Feedster, Technorati, PubSub, etc could make of use it as well.

Robert Sayre

---

From: Graham <[email-masked]>
Date: Sat, 17 Jul 2004 11:32:21 -0400

> but do you have plans or desires to do anything with link constructs 

Yes. I already do.

> links, then what's stopping you from just ignoring the ones you don't

Nothing. But if I ignore them, and everyone else does, the there's no 
need to be able to know an unrecognised one is a link construct, and no 
reason to have such a useless hack as link@rel.

Graham

---

From: Graham <[email-masked]>
Date: Sat, 17 Jul 2004 11:36:30 -0400

On 17 Jul 2004, at 2:32 am, Ken MacLeod wrote:

> more precise link relation names (@rel or in element name)

Well I did write a proposal encouraging the latter.

> or whether

I'm completely against grouping them. There's no reason to and it 
creates an extensibility nightmare.

---

From: Dare Obasanjo <[email-masked]>
Date: Sat, 17 Jul 2004 08:46:15 -0700 (PDT)

--- Robert Sayre <[email-masked]> wrote:
> all types of link elements into account help for
> PageRank-type algorithms? 

I don't think so. 

> I use RSS Bandit to see what it's like subscribing
to
> lots of feeds; way more

I don't see how having the currently overloaded link
element makes this feature any more possible.
SharpReader already provides something close this
feature by tracking how items that link to a
particular URL although it doesn't let you sort by
'most popular links' which should be a trivial
addition. The only reason I don't have this feature in
RSS Bandit is because I haven't had time to figure out
how to implement such a feature efficiently (and I
need to reduce our memory usage and responsiveness
already). 

If you just want to read the most popular links on the
Web then all you need is an RSS feed of Blogdex or
Daypop's daily lists. Most popular links on the Web,
that are showing up in your aggregator is much harder
since you'd have to ping an external service like
Technorati but I'm sure they'd consider it a DoS
attempt if thousands of RSS Bandit instances were
hitting their servers asking for the link cosmos of
hundreds of links a day. 

=====

---

From: Robert Sayre <[email-masked]>
Date: Sat, 17 Jul 2004 11:56:56 -0400

>> PageRank-type algorithms?

OK.

> 
>> I use RSS Bandit to see what it's like subscribing to
>> lots of feeds; way more

I was referring to extension link types in general, not advocating the
current syntax. The beginning of this thread:

>>On 7/16/04 3:47 PM, "Tim Bray" <[email-masked]> wrote:

> that are showing up in your aggregator is much harder...

I just want the most popular links among feeds that I subscribe to, since
those are the sources that I trust. If the aggregator can't recognize
extension link types, it's losing some data points, that's all.

Robert Sayre