Subject: PaceLinkConstruct issues & next steps

From: Tim Bray <[email-masked]>
Date: Tue, 20 Jul 2004 15:21:58 -0700

As I look at the link-related discourse over the past few days, I 
observe a striking lack of consensus around

(a) whether it's useful to class or group links
(b) if so, how this should be done

Furthermore, I think that what progress there was in the discussion has 
been slowing down.  So, I'm casting about for what areas of agreement 
there are and how we can move this along.

Here are the links that we seem to have agreement must be in Atom 
(harvested from format & protocol drafts):

1. website of person (currently <atom:uri>*</atom:uri>)
2. feed-level link to publication (currently <atom:link rel="alternate" 
href="*">)
3. feed-level unique identifier (<atom:id>*</atom:id>)
4. generator uri (<atom:generator uri="*">)
5. basic link from atom:entry to its resource (<atom:link 
rel="alternate" href="*">)
6. entry-level unique identifier (<atom:id>*</atom:id>)
7. service.X endpoints (<link rel="service.X" href="*">)

There are some "secondary" links that have been talked up: via, 
in-reply-to, replaces, next, previous, attachment  (Did I miss any?)

OK, so..... unless someone comes up with a coherent proposal for how to 
do "rel=" and can get consensus around it, I see no choice but to nuke 
it.  That means that every link that anyone wants to have in Atom gets 
its own element or it isn't there.

NEXT STEP.  Since this is decision is quite significant to the look and 
feel of Atom, and since look and feel is important, I don't want to 
declare defeat on link grouping and extension (whatever my personal 
opinions).  So, I think we should push this one back on the stack and 
ask Sam to rotate the work queue.  The people who want to retain rel= 
or some other grouping/extension mechanism should feel free to work up 
proposals, make comparison charts on the wiki, or whatever.  Because, 
next time we take this up, the default action, unless there's consensus 
on grouping/extension, is to go element-by-element.

I'll wait for a day or two to give people a chance to shout one of:
(a) give up and go to distinct elements now
(b) yes, push it on the queue and give us a chance to work something up
(c) hey, there is too consensus on XXXX, you just didn't notice

No shouting => b.

OPINION: I don't think this issue is that big at the end of the day.  
Doing it right will probably give us better readability by end-users, 
but when we make up our minds I think the implementors will say "yeah, 
whatever" and code it up whichever way without any angst.

  -Tim

---

From: Antone Roundy <[email-masked]>
Date: Tue, 20 Jul 2004 18:08:43 -0600

> (b) if so, how this should be done
Agreed--no consensus is emerging.  At best, we're clarifying the 
division between the various opinions.  I suppose that progress of a 
sort.

> So, I think we should push this one back on the stack and ask Sam to 
> rotate the work queue.
+1

In preparation for the final round of discussion, I'd be interested in 
EVERYONE's opinion on one thing.  The discussion on the mail list has 
mostly been carried on by a small number of people, with occasional 
input from a slightly larger group.  I'd like to get a bigger picture 
of where everyone stands (whether you've had specific comments to add 
to the discussion or not) as a guide to one last effort at crafting a 
proposal.

Below is a list of proposals relevant to this discussion (sorry if I 
missed something important).  Could ANY/EVERYONE who cares put these 
roughly in order of how well you like them (best first, worst 
last--note that they are not all mutally exclusive) and email them 
either to the list or to me directly.  (If you email directly to me, 
please leave "PaceLinkConstruct" in the subject--that will ensure that 
your message gets through my SPAM filter).  If there are small details 
in a proposal that you disagree with, but you like the overall 
philosophy behind that, please don't let the small details move it to 
the bottom of your list.

# PaceExtensionNamespace - divide up link/@rel values between Link, 
Service, and Embed Constructs, and give each element its own name. 
Construct types to be regonizable by the presence of a particular 
attribute. (no @rel - extensible outside the Atom core).

# PaceLinkPurpose - tighten the scope of what can go into the link 
element--anything not fitting that scope has to go to some other 
element (keeps @rel - could be extensible, but doesn't specify how)

# PacePersonLinks - replace <url> in Person Constructs with <link>, 
using a variety of @rel values (doesn't comment on extensibility 
outside of the core)

# PaceReplaceLinkElement - replace link/@rel with a number of elements 
(no apparent extensibility outside the core)

# PaceLinkConstruct - use @rel and @rev with a longer list of values 
(fixed list of allowed values -- thus not extensible outside the core)

# PaceLinkAttrDefaults - make "alternate" the default @rel, and make 
@type optional (doesn't comment on extensibility outside of the core)

# PaceUseBrokenLinkSyntaxEverywhere - Not only keep @rel for link, but 
also use it in person and date constructs (doesn't comment on 
extensibility outside of the core)

# PaceLinkRelMechanism - use qnames in @rel for links defined in 
extensions (thus, extensible)

Note: the preceding list is in my approximate order of liking.  I won't 
be put out if you put them in the opposite order--rather I'll be glad 
that you educated me on your point of view.  I'll likewise be glad to 
hear from people who generally agree with this order so that I'll know 
I'm not along.

Thanks all,

Antone

---

From: Eric Scheid <[email-masked]>
Date: Wed, 21 Jul 2004 11:13:55 +1000

> (b) yes, push it on the queue and give us a chance to work something up

+1 shout.

e.

---

From: Antone Roundy <[email-masked]>
Date: Tue, 20 Jul 2004 21:18:08 -0600

> extensions (thus, extensible)
I've been corrected on this one:

"the mechanism described on that page are NOT qnames, but a different 
thing altogether."

and

"PaceLinkRelMechanism isn't using XML qnames, it's using RFC2731 schema 
declarations."

---

From: Norman Walsh <[email-masked]>
Date: Thu, 22 Jul 2004 10:40:22 -0400

/ Tim Bray <[email-masked]> was heard to say:
| I'll wait for a day or two to give people a chance to shout one of:
| (a) give up and go to distinct elements now
| (b) yes, push it on the queue and give us a chance to work something up
| (c) hey, there is too consensus on XXXX, you just didn't notice

(b) is fine, though I'd be happy with (a) because that's my personal
favorite.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Everything the same; everything
http://nwalsh.com/            | distinct.