Subject: PaceLinkConstruct central?

From: Tim Bray <[email-masked]>
Date: Fri, 16 Jul 2004 09:28:48 -0700

On Jul 16, 2004, at 8:25 AM, Graham wrote:
> On 16 Jul 2004, at 11:10 am, Sam Ruby wrote:
>> But mostly, and as Tim indicated [1], I tossed "something big, hairy, 
>> and ugly", namely link/service tags.  This is becoming a bit of a log 
>> jam.  There are six in all
> There's not a PaceNukeTheLinkTag (and turn each @rel into a new 
> element) or equivalent, is there? I think someone needs to write one.

Ouch, I just spent a couple of minutes glancing at all those things in 
the "Currently Under Discussion" section, and while I think I have a 
general feel for the issues, it's going to be hard to get a 
well-structured discussion going.

So, here's a strawman, part 1: First of all, we address the basic 
question of whether
(a) we try to use <link rel="this" href="">, <link rel="that" href="">, 
etc for all our link-flavoured constructs, or
(b) we break 'em out and make a bunch of <this href="">, <that href=""> 
(Graham's NukeTheLinkTag)

It seems to me that if we can solve this syntax problem, it will clear 
the air so we can see the others more quickly (and as a side-effect 
cause most of those six Paces to be retired or rewritten).

My opinion:
Yes, let's sort the syntax mess first, and
(b), just because I hate <link rel="alternate"> for maybe atom's most 
important single tag.

  -Tim

---

From: Sam Ruby <[email-masked]>
Date: Fri, 16 Jul 2004 13:09:59 -0400

> well-structured discussion going.

In many ways, the primary thing that they had in common was that each 
were being either held back (or tossed back) in wait for a pace that had 
yet to be written.  If this fact is the only thing that this cycle has 
highlighted, then it still was a productive cycle.

> cause most of those six Paces to be retired or rewritten).

+1 on solving that first (even if it means that all six get tossed back)

> (b), just because I hate <link rel="alternate"> for maybe atom's most 

If that is the biggest problem: there is a simple solution.  Make 
"alternate" the default for the rel attribute.

I have expressed support[1] for the current link tag before, but I 
certainly will go along with consensus.  I do have one request, however. 
  We don't make decisions based on formulations such as the "this or 
that" paragraph above, but based on somebody doing the hard work of 
drafting spec language for the new approach.

This is harder than one might think...

- Sam Ruby

[1] http://www.imc.org/atom-syntax/mail-archive/msg04224.html

---

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

> (Graham's NukeTheLinkTag)

strawman indeed ;-)

you left out:
(c) break some links out to their own elements (<this href="">) but leave
the generalised case of <<there is a resource you may be interested in
retrieving, it's relationship to me is 'blah'>> as <link rel="blah">

e.

---

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

Eric Scheid <[email-masked]> writes:

> (c) break some links out to their own elements (<this href="">) but
> leave the generalised case of <<there is a resource you may be
> interested in retrieving, it's relationship to me is 'blah'>> as
> <link rel="blah">

Are the values in @rel fixed or extensible?  If you address the
extensibility issue in @rel, we don't need <this .../>.  If the values
in @rel are fixed, then it makes all extended links second-class.

  -- Ken

---

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

> in @rel are fixed, then it makes all extended links second-class.

For (c), I say @rel would be extensible, but I am also saying that <link> be
restricted to just those links which are 'hyperlinks', not service entry
points, not references to resources for transclusion or performing
transformations with. That is, consider <link> to be for the same generic
purpose which <url> in <person> and <generator> serves. It's simply a URL to
some retrievable resource related in some ambiguous way to the parent
element. 

For the case of <link> standing in for <url> in <person> and <generator>,
I'd be happy to have @rel be optional. It's just a generic link. The
provision of @rel serves to refine the relationship, but can be ignored if
necessary.

Assuming PaceLinkPurpose is implemented, and thus all the URIs in <link>
elements are traversable, we could even allow @rel to be optional there too.
It would serve the bland purpose of saying "here is some other resource you
might care to retrieve". Throw in @title and users would know if it's sane
to go traverse that link. Throw in @type and users would know if their
browser will handle it, or if it is a PDF, or a quicktime movie.

e.