Subject: PaceLinkPurpose

From: Dare Obasanjo <[email-masked]>
Date: Fri, 8 Oct 2004 10:45:33 -0700 (PDT)

+1 on this Pace. Fold it into the spec, I agree 100%
with the rationale. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #23
I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks.

_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

---

From: Danny Ayers <[email-masked]>
Date: Fri, 8 Oct 2004 20:14:50 +0200

+0.

I like the idea of tightening the semantics, but "logically be
presented to the user as clickable links" doesn't help much. At one
extreme only GETtable hyperlinks fit the bill, at the other *anything*
could be presented as a clickable link.

"Links to other resources must be made using a different element." -
so what would a logically clickable link be linking to??

(This is all aside from the reliance on a specific user interface component.)

But if the definition can be made more useful, then I'd back this
Pace, though would hope that the (controlled) extensibility point
offered by 'rel' wasn't lost in the process.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Graham <[email-masked]>
Date: Fri, 8 Oct 2004 19:30:01 +0100

I like it but don't think it goes far enough, or that its wording is 
viable (clicakable/not-clickable is not a valid axis). There are 
basically 4 types of link:

alternate - special case
related - related, via, etc
service
image - favicons and logos

We already have a special element for service (don't we?). The next 
step is to break out all the other types and drop the generic <link> 
element completely.

Graham

---

From: Dare Obasanjo <[email-masked]>
Date: Fri, 8 Oct 2004 11:33:06 -0700 (PDT)

> could be presented as a clickable link.

I don't see where you get your other extreme from. How
can *anything* be presented as a clickable link?
Please give examples. 
 
> offered by 'rel' wasn't lost in the process.

Define more useful. As it is PaceLinkPurpose turns the
most ambiguous and poorly designed aspect of Atom into
a well-defined, consistent and usable extensibility
point. How would you improve it?

=====

---

From: Danny Ayers <[email-masked]>
Date: Fri, 8 Oct 2004 20:48:30 +0200

> can *anything* be presented as a clickable link?

What is presented could be a labelled hyperlink,
System.Windows.Forms.Button, image or whatever. The actions could be,
for some value of 'rel':

start, next, prev, comments, alternate, source, via, in-reply-to -
opens the href URI in a browser window

versions, trackback, - opens the feed of versions, trackbacks in an aggregator

transform.input, transform.output  - apply the XSLT, display in browser

icon, logo - display the icon/logo

service.post, service.edit - open an editor pre-loaded with verb &
target URI details

service.feed - open the feed in an aggregator

> Define more useful. 

Offering classification of the rel values that could help with implementation.

As it is PaceLinkPurpose turns the
> point. How would you improve it?

How about making it unambiguous and extensible?

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Antone Roundy <[email-masked]>
Date: Fri, 8 Oct 2004 13:03:13 -0600

On Friday, October 8, 2004, at 12:14  PM, Danny Ayers wrote:
> extreme only GETtable hyperlinks fit the bill,
That's basically what I was getting at, as suggested by the proposed 
spec text.  (BTW, "logically be presented to the user as clickable 
links" is not proposed spec text, so ultimately, if that's not a good 
way to express the idea, it doesn't matter much).

> offered by 'rel' wasn't lost in the process.
Here's the proposed spec text that defines the semantics:

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. When accessing the resource 
pointed to by the href attribute using HTTP, the GET method MUST be 
used.

---

From: Danny Ayers <[email-masked]>
Date: Fri, 8 Oct 2004 21:00:00 +0200

> image - favicons and logos

Yep, that's more like it.

> step is to break out all the other types and drop the generic <link>

I agree with the former suggestion, but dropping link as an extension
point would be a step backwards.

Cheers,
Danny.

---

From: Antone Roundy <[email-masked]>
Date: Fri, 8 Oct 2004 13:10:56 -0600

On Friday, October 8, 2004, at 12:30  PM, Graham wrote:
> There are basically 4 types of link:
>
> alternate - special case
I see "alternate" as a "related" type, though I'd agree it's possible 
to make a distinction.  I'm just not sure it's terribly useful to do so.

> service
Yes, we already have a separate element.

> image - favicons and logos
These haven't made it into the link element yet, though they've 
appeared in proposals.

---

From: Antone Roundy <[email-masked]>
Date: Fri, 8 Oct 2004 13:35:22 -0600

On Friday, October 8, 2004, at 12:48  PM, Danny Ayers wrote:
> The actions could be, for some value of 'rel':
>

So we have "opens in a browser" and "opens in an aggregator".  Not so 
different from clicking a link to a PDF on the web today.  It may open 
in a browser window or launch Acrobat's UI.  Same for various audio and 
video types, etc.  I don't think what it opens in really matters.

Nothing below here is a valid @rel value in the current spec, as it is 
scheduled to be amended based on proposals that have been accepted.  
(And I don't think any of them belong in <link>).

---

From: Eric Scheid <[email-masked]>
Date: Sat, 09 Oct 2004 12:45:49 +1000

> Yep, that's more like it.

transform.input, transform.output?

links to CSS?
links to javascript? (god forbid!)

e.

---

From: Eric Scheid <[email-masked]>
Date: Sat, 09 Oct 2004 12:52:43 +1000

On 9/10/04 5:03 AM, "Antone Roundy" <[email-masked]> wrote:

[spec text]

> pointed to by the href attribute using HTTP, the GET method MUST be

s/activated/traversed/ ?

Problem: "GET method MUST be used" disallows the use of HEAD for it's useful
reasons. The intent, iirc, was to disallow POST and similar access methods
requiring more payload than just the URI.

It also disallows PROPFIND and OPTIONS and maybe other methods too, but
since I know squat about these I don't know if that is good or bad.

e.

---

From: Eric Scheid <[email-masked]>
Date: Sat, 09 Oct 2004 13:51:07 +1000

+1, but the spec text needs improvement

> offered by 'rel' wasn't lost in the process.

+1 to tackling this problem by suggesting improved camera ready spec text.

e.

---

From: Eric Scheid <[email-masked]>
Date: Sat, 09 Oct 2004 13:57:07 +1000

+1 to limiting <link> to traversable hyperlinks
+1 to allowing the possibility for extensibility

e.

---

From: Graham <[email-masked]>
Date: Sat, 9 Oct 2004 15:25:39 +0100

> to make a distinction.  I'm just not sure it's terribly useful to do 

Alternate is another version of what your already seeing. Related, via 
etc all link to things that are completely different.

> These haven't made it into the link element yet, though they've 

There's no canonical list. Last I checked the format spec just refers 
you to the list in the protocol spec, which has what can at best be 
described as a placeholder for a real list.

Graham

---

From: Antone Roundy <[email-masked]>
Date: Sat, 9 Oct 2004 11:10:28 -0600

>> pointed to by the href attribute using HTTP, the GET method MUST be
Yes, that's better.  Updated.

> since I know squat about these I don't know if that is good or bad.
Changed "accessing" to "retrieving", which at least improves it.

Any other suggestions for improvement?