Subject: RE: PaceEntryOrigin

From: "Bob Wyman" <[email-masked]>
Date: Sun, 4 Jul 2004 19:11:03 -0400

Re: PaceEntryOrigin

      1) Clearly, I'm missing something very important in the way people are
thinking about Atom... I simply don't understand why everyone seems to
insist on overloading the link element whenever possible. It seems to me
that link, if used at all, would provide an interesting way to accommodate a
number of add-on extensions. However, if we know up-front that there is some
data that we want to have in a "standard" Atom feed or entry, why in the
world use link? Why not just provide an element which is custom designed for
the specific data? What does link give us that we can't get from a specific
element?

      Clearly, I think PaceEntryOrigin should *not* use link, but rather
have a specific element, like the "source-feed" element that we discussed at
the Atom community meeting and that PubSub.com has been supporting in its
Atom-over-Jabber feeds.

      2) As I have stated before, I think that when building a composite
feed, we need to communicate more than simply the URI of the origin feed.
Minimally, we should be able to pass along the title of the feed in addition
to the URI. It may also be necessary to pass along the copyright and/or
rights statements for the feed from which an entry was extracted. And, it
might even be reasonable to pass along information about the modified time
of the source feed. I think I could create reasonable arguments for needing
to pass *any* or *all* of the source feed's metadata.

      However, the current draft of PaceEntryOrigin only provides explicit
support for the URI (even though title is mentioned in the notes.) In any
case, since PaceEntryOrigin is relies on link, if accepted, we wouldn't be
able to include any data that couldn't be encoded in an attribute. If this
is the case, then let's just remove all the elements from feed and replace
them with attributes... If attributes are ok for PaceEntryOrigin, then they
must be ok for the feed itself...

      3. Let me provide an example of an application for PaceEntryOrigin: As
has been mentioned before, we at PubSub.com provide Atom feeds over the
Jabber/XMPP IM protocol. We've recently released via SourceForge,[1] a quick
little .NET application that allows you to receive notifications of updates
to RSS/Atom files in a window on your Windows desktop.[1] Notifications are
sent to the client application using Atom over Jabber and each notification
displayed contains: The date the entry was issued, the Title and URI of the
entry and the Title and URI of the feed the entry was taken from. An entry
in the display looks something like what you see below:

 <http://www.newsgator.com/news/archive.aspx?post=40> NewsGator
Technologies, Developer of Leading RSS Tools and Services, Closes Series A
Funding 

 <http://www.newsgator.com/> NewsGator News and Updates

Wed, 23 Jun 2004 06:15:00 GMT 

      Of course, people who write their own applications can get the full
content of the entry sent to them; however, we find that the minimal useful
content concerning an entry consists of the five elements that we display in
our application. I would very much like to be able to use "standard Atom" to
encode these notifications - but as PaceEntryOrigin is currently written, I
would have to continue to do something "proprietary" or non-standard in
order to pass the title of the origin or source feed. (I.e. I would have to
continue to use the ps:source-feed element that we've been using to-date.)
This is not a good thing. Also, I think it is not hard to imagine that some
people will claim that it is desirable to allow users to display additional
information such as feed copyright or rights, feed modification times, feed
descriptions, feed authors, etc. in this sort of display. But, if
PaceEntryOrigin doesn't provide for all that data to be attached to an
entry, I'm once again stuck doing non-standard stuff. 

      I strongly argue that PaceEntryOrigin should be based on a distinct
element (atom:origin would be fine), not an overloading of <link/> and that
it should be possible for the atom:origin element to carry any and all
feed-level meta-data. I am opposed to PaceEntryOrigin in its current form.

            bob wyman

[1] http://sourceforge.net/projects/pubsubxmpp/

---

From: Robert Sayre <[email-masked]>
Date: Sun, 04 Jul 2004 19:47:18 -0400

On 7/4/04 7:11 PM, "Bob Wyman" <[email-masked]> wrote:

> thinking about Atom... I simply don't understand why everyone seems to insist
> on overloading the link element whenever possible.

I'll troll again:
http://www.imc.org/atom-syntax/mail-archive/msg06039.html

Who is in favor of using the link element at all?

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Mon, 05 Jul 2004 12:39:52 +1000

> Who is in favor of using the link element at all?

here is some psuedo-code for handling the <link> element...

    getEntryElements(theEntryNode)
    for each <link>
        injectLink(href,title,type, rel)
    end. 

on the other hand, the psuedo-code to handle all manner of different element
names (including namespaced extensions) would be quite a bit longer, and
also pretty much incapable of handling link types which are unknown at the
time of writing the code.

e.

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 5 Jul 2004 01:29:11 -0700 (PDT)

> time of writing the code.

I find this argument very suspect. Your argument
assumes that all <link> elements are similar enough
that they can be treated in some default identical
manner by Atom consumers. As an aggregator author,
lets assume I decide to render all links that are part
as hyperlinks that the user can click on. Let's see
whether this default logic works for the proposed link
types thus far. Taking a look at 
http://intertwingly.net/wiki/pie/LinkTagMeaning I
count about 14 or 15 values for the rel attribute. If
I implemented the same behavior for all 14 types of
links in RSS Bandit [render a clickable link], at
least half of these could be considered incorrect ways
to support these features (e.g. service.edit,
service.post, comments, transform.input,
transform.output, icon, etc). Making all these things
links is misleading since it implies that they can be
treated consistently when in truth they cannot. 

The entire concept of extensibility through <link>
elements is built on a faulty premise and is an
example chasing of a false goal[0]. 

Also, the focus on link based extensions ignores the
fact that lots of extensions to entries won't be links
if history from RSS is any guide[1, 2,3]. 

[0]
http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=fbe8824b-79e5-459d-98b0-b7153d0eda0e
[1]
http://blogs.law.harvard.edu/tech/directory/5/specifications/rss20ModulesNamespaces
[2] http://web.resource.org/rss/1.0/modules/dc/
[3] http://web.resource.org/rss/1.0/modules/dcterms/

=====
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!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 05 Jul 2004 10:26:52 +0100

Bob Wyman wrote:

>       1) Clearly, I'm missing something very important in the way people 
> are thinking about Atom... I simply don't understand why everyone seems 
> to insist on overloading the link element whenever possible. 

Not "everyone". If you look through the archives you will see a 
number of people have questioned the way link is used.

> have a specific element, like the "source-feed" element that we 
> discussed at the Atom community meeting and that PubSub.com has been 
> supporting in its Atom-over-Jabber feeds.

The Pace's mainline wording has such an element. The link option I 
provided, because it seemed to me, inevitable, that it would arise 
in discussion.

> feed, we need to communicate more than simply the URI of the origin 
> feed. Minimally, we should be able to pass along the title of the feed 
> in addition to the URI. It may also be necessary to pass along the 
> copyright and/or rights statements for the feed from which an entry was 
> extracted. And, it might even be reasonable to pass along information 
> about the modified time of the source feed. I think I could create 
> reasonable arguments for needing to pass *any* or *all* of the source 
> feed's metadata.
 >
 > [...]
>       I strongly argue that PaceEntryOrigin should be based on a 
> distinct element (atom:origin would be fine), not an overloading of 
> <link/> and that it should be possible for the atom:origin element to 
> carry any and all feed-level meta-data. I am opposed to PaceEntryOrigin 
> in its current form.

Will you propose atom:origin have child elements? Otherwise if you 
want these things, then you should create arguments for them - feel 
free to update the wiki page with such an option.

cheers
Bill

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 05 Jul 2004 10:31:03 +0100

> time of writing the code.

I don't buy that argument. The way link is currently to supply 
control codes, you will have a switch somewhere.  In your case it 
will be inside injectLink(). So, above, how will I handle the rel I 
haven't seen before?

cheers
Bill

---

From: Eric Scheid <[email-masked]>
Date: Mon, 05 Jul 2004 20:16:10 +1000

> will be inside injectLink(). So, above, how will I handle the rel I

do you mean a switch like

    if @rel is in {known & linkable} then
        write <a> link

or do you mean a switch like

    if @rel is not in {known & unlinkable} then
        write <a> link

e.

---

From: Eric Scheid <[email-masked]>
Date: Mon, 05 Jul 2004 21:06:08 +1000

On 5/7/04 6:29 PM, "Dare Obasanjo" <[email-masked]> wrote:

> manner by Atom consumers.

Well, there *is* a pace suggesting that non-clickable <link>s like
'service.edit' be done in some other element.

> As an aggregator author,
> as hyperlinks that the user can click on.

Why handicap yourself? As an aggregator *user* I already do more than simply
"click" on hyperlinks. One example: in my pubsub feeds I sometimes drag the
blog URL to NNW's subscription panel, which usually causes NNW to subscribe
to the feed for that blog. No side trip to a browser necessary.

(it fails where the auto-discovery links at the site are not 100%, but if
pubsub had the feed URI in the entry

> Let's see whether this default logic works for the proposed link types thus
> far. Taking a look at http://intertwingly.net/wiki/pie/LinkTagMeaning I count
> about 14 or 15 values for the rel attribute.

Whoa there nellie! Some of those @rel values are for feed level links only.
I count 11 which are usable at the entry level (and six which are feed level
... are there some which you are not counting?)

> If I implemented the same behavior for all 14 types of links in RSS Bandit
> [render a clickable link], at least half of these could be considered
> incorrect ways to support these features (e.g. service.edit, service.post,
> comments, transform.input, transform.output, icon, etc). Making all these
> things links is misleading since it implies that they can be treated
> consistently when in truth they cannot.

Considering only the rel values relevant to entries, there are then just 2
link types which are not directly usable: service.post and service.post ...
which as noted above may not even end up being in <link> elements.

> Also, the focus on link based extensions ignores the fact that lots of
> extensions to entries won't be links if history from RSS is any guide[1, 2,3].

I don't know anyone who is suggesting that (eg) <dc:subject> should be
written as <link>, or that the utility of <link> excludes the possibility of
<dc:subject>

e.

---

From: Antone Roundy <[email-masked]>
Date: Mon, 5 Jul 2004 08:28:01 -0600

> time of writing the code.
+1.  I'm in favor of <link>, but also in favor of limiting its scope as 
noted in PaceLinkPurpose.  Sure, people try to overload it with too 
many uses, but I'm not convinced that throwing it out altogether is the 
way to go.  It could be argued that link[@rel='start'], 
link[@rel='next'], and link[@rel='prev'] could all go into a <navigate> 
element or something--that provides nice grouping.  But on the other 
hand, those things clearly ARE links whether they end up being <link>s 
or not.  Turning those three into <start>, <next> and <prev> on the 
other hand, would result, I think, in far too many different elements 
that all do almost exactly the same things--it creates clutter. 
<navigate> would be a less extreme example of the same thing.

---

From: Antone Roundy <[email-masked]>
Date: Mon, 5 Jul 2004 08:41:53 -0600

> 'service.edit' be done in some other element.
In addition to PaceLinkPurpose, there's a specific proposal for 
service.*: PaceServiceElement.  PaceLinkPurpose would require new 
solutions for transform.input, transform.output, and icon as well, 
reducing the list in LinkTagMeaning from 16 to 10 distinct values.  
Assuming that in a feed reader, clicking a link to a feed (or entry in 
Atom format) works better than it does in the average web browser, the 
rest would not be unreasonable to render as a clickable link.

http://www.intertwingly.net/wiki/pie/PaceLinkPurpose
http://www.intertwingly.net/wiki/pie/PaceServiceElement
http://www.intertwingly.net/wiki/pie/LinkTagMeaning

---

From: Robert Sayre <[email-masked]>
Date: Mon, 05 Jul 2004 11:39:49 -0400

On 7/5/04 4:29 AM, "Dare Obasanjo" <[email-masked]> wrote:

> I find this argument very suspect.

As do I. The other mechanisms that have been proposed (xlink, rdf/xml, etc)
are all capable of handling unknown link types.

> if history from RSS is any guide[1, 2,3].

Faulty premise indeed. html:link is broken and underspecified [4]. Browser
authors appear to deal with it as legacy baggage. No one uses the damn thing
in HTML and we've glommed onto it like it's the best thing ever! I agree
with Bob Wyman. I don't get it.

Robert Sayre

> [3] http://web.resource.org/rss/1.0/modules/dcterms/

[4] http://www.hixie.ch/specs/html/link/

---

From: Eric Scheid <[email-masked]>
Date: Tue, 06 Jul 2004 02:09:49 +1000

> are all capable of handling unknown link types.

You do realise that xlink has much more complicated semantics of linking,
right? For example, it has an attribute 'type' which could have values of
"simple", "extended", "locator", "arc", "resource", "title", or "none". Then
there are the other attributes like 'actuate'.

Do we really want to require atom applications to handle such a complicated
thing?

e.

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 5 Jul 2004 09:50:17 -0700 (PDT)

> handle such a complicated

As link is currently being used in Atom it is quite
USELESS for aggregator authors to use it to do
anything meaningful with unknown links. At list with
XLink it allows finer grained semantics about the link
to be passed around besides title and URI. 

The simplicity you claim currently exists is due to
link being horribly underspecified not from some
elegant simplicity. 

Personally I think th etime has come to scale bank
this overuse of link and muddy semantics it
introduces. Atom is supposed to be a tightly specified
spec that helps aggregator authors. The current usage
of the link elements makes a mockery of that claim. 

=====

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

---

From: Eric Scheid <[email-masked]>
Date: Tue, 06 Jul 2004 03:19:40 +1000

On 6/7/04 2:50 AM, "Dare Obasanjo" <[email-masked]> wrote:

> The simplicity you claim currently exists is due to link being horribly
> underspecified not from some elegant simplicity.
> 

Please identify in what ways <link> is underspecified. Perhaps all that is
needed is, um, specification text to be written.

So ... what parts of the 0.3 spec is ambiguous/contradictory/silent w.r.t.
<link>? In what ways can <link> be interpreted in more than one way that
will lead to confusion or interoperability problems?

e.

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 5 Jul 2004 10:14:26 -0700 (PDT)

> 'service.edit' be done in some other element.

That's a start. I'd also like to see some tightening
of the text around links providing guidelines for waht
should or should not be a link. It seems there are
currently a lot of Paces around link which makes it
hard to figure out which way forward to me. 
 
> to the feed for that blog. No side trip to a browser

The point of my example is that as currently
specified, the semantics of the various links is
inconsistent so aggregator authors can't just write
some generic foreach loop and process all links
identically. 

I'm also not sure what your example with NNW has to do
with anything. RSS Bandit has the same functionality
and I see it as orthogonal with dealing with how one
processes links in a generic manner. 

> which as noted above may not even end up being in

I'd also count comments as not being directly usable
if clicked on directly.  However you do point out that
feed level links are quite problematic since the
majority of the links with inconsistent semantics as
links are feed level links.  

=====

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

---

From: Eric Scheid <[email-masked]>
Date: Tue, 06 Jul 2004 03:47:26 +1000

On 6/7/04 3:14 AM, "Dare Obasanjo" <[email-masked]> wrote:

> The point of my example is that as currently specified, the semantics of the
> various links is inconsistent so aggregator authors can't just write some
> generic foreach loop and process all links identically.

if PaceLinkPurpose is accepted, then the semantics are quite clear: the
<link> element provides a usable link between the entry and some other
resource, described by the @rel attribute. I'm not real happy about
"clickable" as usable can include drag/drop instead.

> I'm also not sure what your example with NNW has to do with anything. RSS
> Bandit has the same functionality and I see it as orthogonal with dealing with
> how one processes links in a generic manner.

it was a counter to your assumption:

    >> As an aggregator author, lets assume I decide to render
    >> all links that are part [of the entry] as hyperlinks that
    >> the user can click on.

I'm saying there are different things that can be done, apart from just
"clicking".

If we assume that links only exist to "click", and by that I assume result
in the linked resource being loaded into a browser window somewhere, then it
wouldn't make any sense to click on links which lead to atom feeds since no
one wants to read xml gobbledegook. However, if we assume that more things
can be done than simply "click", then a link to xml resources could be very
handy.

>> link types which are not directly usable: service.post and service.edit ...
> I'd also count comments as not being directly usable if clicked on directly.

Why would "An Atom Feed for all comments on just this entry" not be useful
if "clicked" on directly (where "clicked" includes "dragged to subscriptions
panel in lieu of one-click subscription mechanisms")?

> However you do point out that feed level links are quite problematic since the
> majority of the links with inconsistent semantics as links are feed level
> links.  

Yes, it appears there are two classes of semantics: there are URIs which can
be GETted to retrieve an interesting resource, which has a relationship with
the current entry as specified in @rel; and secondly there are URIs which
don't return anything useful in response to a GET, but instead require some
other process (such as POST, or retrieving a stylesheet resource and
applying that to the entry).

PaceLinkPurpose proposes that <link> be limited to just the first semantic.

e.

---

From: Graham <[email-masked]>
Date: Mon, 5 Jul 2004 14:09:52 -0400

I'd like to join Dare and everyone else in saying the link tag as it 
stands is absolutely horrible (I'm being polite today). The public are 
already abusing it by putting unlisted values in @rel. Atom members are 
already abusing it by introducing features through new rels that would 
never get through if they required a new element. The worst thing is 
that it's stolen from HTML, so every time someone suggests a 
modification that makes it more useful, but incompatible with HTML, 
they get shouted down for confusing the ViewSourceClan. Plus it has the 
body - the URI - in an attribute, unlike every other element we have. 
And where's the extension mechanism?

The only sane thing to do is forget it ever existed and work out 
*appropriate* mechanisms for the functionality it orphans.

Graham

---

From: Antone Roundy <[email-masked]>
Date: Mon, 5 Jul 2004 15:20:54 -0600

> "clickable" as usable can include drag/drop instead.
The way feed readers usually work today, clicking a link does tend to 
imply that the target of the link is going to open in a web browser 
window, but I expect that to change, and in fact, the winds of change 
are blowing already.  (If no such change were coming, then I'd agree 
that "clickable" would be the wrong word to express the idea.)  The 
"winds of change" are things like people implementing "feed://", which 
opens a feed in a browser--non standard, yes, but the fact that people 
are doing it shows that there is a demand for some way of getting feeds 
to open in a feed reader automatically.

Following a link to a feed shouldn't always result in subscribing to 
the feed.  For example, following link[@rel="start"], link[@rel="next"] 
and link[@rel="prev"] are ways to see more of the current feed--they 
shouldn't result in an additional subscription.  Also, just as clicking 
a link to a webpage does not automatically bookmark the page, there's 
no reason why clicking a link to a feed should automatically subscribe 
you to it. It should load the feed in your feed reader, and then you 
should be able to subscribe to it if it looks interesting enough.  (How 
many times have you subscribed to a feed to see if it looked like you 
wanted to subscribe to it, only to unsubscribe immediately?  I've done 
it many times).

So there's my defense of the word "clickable" in this context.  It 
certainly doesn't preclude dragging and dropping, but as I imagine the 
results of a click, it covers what I think <link> should be used for.

---

From: Antone Roundy <[email-masked]>
Date: Mon, 5 Jul 2004 15:34:13 -0600

On Monday, July 5, 2004, at 12:09  PM, Graham wrote:
> already abusing it by putting unlisted values in @rel. Atom members 
> are already abusing it by introducing features through new rels that 
> would never get through if they required a new element. The worst 
> thing is that it's stolen from HTML, so every time someone suggests a 
> they get shouted down for confusing the ViewSourceClan. Plus it has 
> the body - the URI - in an attribute, unlike every other element we 
> have. And where's the extension mechanism?
>
The ViewSourceClan has not shouted PaceLinkPurpose down.  Unless I'm 
misperceiving, the comments that have been addressed to it have been 
almost universally positive (so far!)

I don't think we can throw a feature out on the basis of it's having 
been abused while in development.  But if that's what you really want 
to do, how about writing proposals to replace each of the @rel values.  
And please don't lump them all together into one--given that all 
existing and proposed links are not similar enough that you're 
comfortable having them all handled by one element, I think they're 
different enough that we need to be able to consider them in logical 
groups rather than all at once.  If all the alternative proposals get 
accepted, then link will be gone without having to decide to drop it.  
I've written PaceServiceElement to take care of the ones that I'm most 
interested in having changed.  There are 4 more values in the current 
spec, or 13 more in LinkTagMeaning.

---

From: Joe Gregorio <[email-masked]>
Date: Tue, 6 Jul 2004 08:11:45 -0400

> Do we really want to require atom applications to handle such a complicated

Also any consideration of XLink would have to take into 
acccount the fact that the xlink:type attribute is a *mandatory*
attribute that MUST be present on every element
that uses xlink, even if it is just simple linking,
i.e. xlink:type="simple".

All the more reason to consider SkunkLink.

    Thanks,
    -joe

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 07 Jul 2004 17:05:02 +0200

> All the more reason to consider SkunkLink.

+1. I'm all in favour of SkunkLink. Seems like a neat specification, and  
won't have too much impact on how Atom looks today.

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Graham <[email-masked]>
Date: Wed, 7 Jul 2004 16:24:31 -0400

On 5 Jul 2004, at 5:34 pm, Antone Roundy wrote:

> been abused while in development.

The point was that it's incredibly open to abuse and confusion.

> But if that's what you really want to do, how about writing proposals  
> to replace each of the @rel values.  And please don't lump them all  
> together into one.

The proposal would be to make a separate element (probably all Link  
Constructs [1]) out of every current rel value, and then see how (and  
whether) we need to group them together from there. I would write a  
Pace but it would require spec text for all of the current @rel values,  
which at present doesn't seem to exist (another reason to ditch the  
stupid things).

Graham

[1]  
http://www.mnot.net/drafts/draft-nottingham-atom-format 
-02.html#rfc.section.3.4

---

From: Eric Scheid <[email-masked]>
Date: Thu, 08 Jul 2004 08:37:33 +1000

On 8/7/04 6:24 AM, "Graham" <[email-masked]> wrote:

> I would write a  Pace but it would require spec text for all of the current
> @rel values,  which at present doesn't seem to exist (another reason to ditch
> the  stupid things).
> 
please clarify: ditch the mechanism for specifying URIs of interest to the
feed/entry, or ditch the concept of different URIs being distinguishable
from each other in some machine readable manner, or ditch the current set of
URI relationships?

e.

---

From: Graham <[email-masked]>
Date: Wed, 7 Jul 2004 19:02:42 -0400

> from each other in some machine readable manner, or ditch the current 

None of the above. Ditch the way rel is currently expressed, such that:

  <link rel="XXX" href="a" title="b" type="c" />
becomes:
  <XXX href="a" title="b" type="c">

In other words, the rel value becomes the element name. No lost 
functionality, just changed syntax. This is already how the various 
different date constructs (and content constructs and person 
constructs) distinguish their meaning in a machine readable manner.

Graham Parks

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 7 Jul 2004 16:49:35 -0700 (PDT)

> will lead to confusion or interoperability problems?

In the Atom 0.3 syndication spec it implies that there
is a fixed list of rel values which seems to
contradict the Atom API spec which implies that there
can be user defined rel values. 

If the list is fixed, then the link element is merely
inconsistent as opposed to underspecified. However if
it allows user defined rel values then it is grossly
underspecified. The question is which is it? 

=====

		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

---

From: Eric Scheid <[email-masked]>
Date: Thu, 08 Jul 2004 11:05:16 +1000

> underspecified. The question is which is it?

I would prefer allowing user-specified values, but in what way is that
under-specified? You say it is under-specified, but you don't say in what
way -- that is not helpful.

Surely you are not asking that all future user-specified values be specified
now?

Perhaps what is needed is spec text along the lines of "an Atom aggregator
MAY ignore links with @rel values it does not recognise". That, combined
with PaceLinkPurpose to limit use of <link> to user-actionable links
retrieved via GET would just about cover it, no?

e.

---

From: Robert Sayre <[email-masked]>
Date: Wed, 07 Jul 2004 22:47:59 -0400

> retrieved via GET would just about cover it, no?

No, it really doesn't. There have been numerous technical objections to
<link>, and none of them have been adequately addressed, IMO.

I can't think of a single technical reason to use <link>. Everything
argument for it is aesthetic or social. Furthermore, it is usually the same
3 or 4 vociferous people that defend it on those grounds.

> <XXX href="a" title="b" type="c">

Graham's suggestion would seem to be superior in every respect.

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Thu, 08 Jul 2004 14:04:08 +1000

>[various opinions]

I'm taking this thread off list for now since it isn't in AtomPubIssuesList

My apologies for the noise.

e.

---

From: Antone Roundy <[email-masked]>
Date: Wed, 7 Jul 2004 22:58:51 -0600

I'm warming somewhat (but not entirely convinced yet) to the idea of 
having a number of elements that are Link Constructs rather than 
putting everything into <link>. I'd still be in favor of 
PaceLinkPurpose to tighten the purpose of Link Constructs, even if the 
<link> element goes away.

On Wednesday, July 7, 2004, at 07:05  PM, Eric Scheid wrote:
> That, combined

Some nice wording in here, which I've used or adapted to improve 
PaceLinkPurpose, getting rid of the word "clickable", among other 
things. Here's the changed text:

3.4 Link Constructs
A Link construct specifies a hyperlink primarily intended to be 
activated through explicit user interactions such as clicking, 
selecting a menu item, drag and drop, etc. The resource pointed to by 
the href attribute MUST be accessed using the GET method.

One other change made to PaceLinkPurpose was to add a "Key Questions" 
section which I believe addresses the main arguments I've heard on this 
topic. The idea behind question #2 is largely responsible for my 
warming to abolishing the <link> element. If we have an easy, 
foolproof, in the spec way of identifying a Link Construct, and know 
that we can handle ANY Link Construct in a generic way if we don't 
understand it specifically, one of the major advantages of <link 
@rel="?" /> (as altered by PaceLinkPurpose, ie. extensibility) 
disappears.

The "Key Questions" are:

    1. Do we want an extensible linking mechanism to enable software 
agents that don't understand the extension to be able to render 
extended links without the risk of rendering them in a manner 
inconsistent with their purpose?
    2. Are there preferable methods for specifying an extensible linking 
mechanism? (For example, could we say that any element with an href 
attribute MUST be a Link Construct, with all the specified attributes 
for Link Constructs, which could be rendered as a user-activatable link 
to be loaded using GET, and which does not require understanding of any 
additional attributes in order to process it in an acceptable way?)
    3. Are we satisfied with <link> as it is, with a closed list of @rel 
values?
    4. Do we want a multiplicity of Link Constructs, or one <link> 
element whose @rel (ore @rev) attribute determines what it is?

---

From: Antone Roundy <[email-masked]>
Date: Thu, 8 Jul 2004 08:05:00 -0600

On Wednesday, July 7, 2004, at 10:58  PM, Antone Roundy wrote:
> The resource pointed to by the href attribute MUST be accessed using 
> the GET method.
Eric pointed out to me that requiring GET would exclude non-HTTP 
access, so I've changed this sentence to "When accessing the resource 
pointed to by the href attribute using HTTP, the GET method MUST be 
used."

> If we have an easy, foolproof, in the spec way of identifying a Link 
> Construct, and know that we can handle ANY Link Construct in a generic 
> way if we don't understand it specifically, one of the major 
> advantages of <link @rel="?" /> (as altered by PaceLinkPurpose, ie. 
> extensibility) disappears.
Perhaps I should have said that one of the major advantages is 
lessened--it WOULD be more difficult to find Link Constructs that one 
didn't fully understand than to find <link> types that one didn't fully 
understand, because the one would require looking at all elements, and 
the other would only require looking at all <link> elements.  Still, 
that's something I think I could live with.

One other change that occurs to me might make abolishing <link> more 
palatable would be if the spec[1] were to group the elements that are 
Link Constructs under a common heading--for example, if section 4.4 
were to be changed from '"atom:link" Element' to  "Link Constructs", 
and have '4.4.1 "atom:start" Element', '4.4.2 "atom:next" Element', 
etc. added underneath it (as opposed to '4.4 "atom:start" Element', 
'4.5 "atom:next" Element', etc.).  The same could be done at 4.13.2, 
and also for date and content constructs.  One of the objections that 
has been raised to abolishing <link> is that it results in a large 
number of elements, which LOOKS more daunting than less elements with 
more options for each.  Grouping similar elements wouldn't shorten the 
list, but by organizing it, would make it more approachable.

[1] http://www.mnot.net/drafts/draft-nottingham-atom-format-02.html -- 
the link, for your convenience