Subject: The link discussion

From: Tim Bray <[email-masked]>
Date: Sat, 09 Oct 2004 10:18:49 -0700

It's pretty obvious we've got some serious work in front of us getting 
to a consensus position.  I'd welcome meta-discussion suggestions as to 
how we might focus and move the discussion towards convergence.  -Tim

---

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

On Saturday, October 9, 2004, at 11:18  AM, Tim Bray wrote:
> to a consensus position.  I'd welcome meta-discussion suggestions as 
> to how we might focus and move the discussion towards convergence.

Of the proposals under discussion, PaceDateOfSubject is obviously not 
part of this question. PaceLinkTitle is also an independent issue.  
That leaves us with the following to address:

PaceLinkAttrDefaults, PaceLinkConstruct, PaceLinkDelicious, 
PaceLinkParent, PaceLinkPurpose, PaceLinkRelMechanism, 
PaceReplaceLinkElement

...and perhaps the follow new proposals created in response to the 
current discussion:

PaceRelationshipConstruct, PaceConstructAttribute, PaceLinkRelPrefix

Here's a way to group the above:

Extensibility: PaceLinkRelMechanism, PaceRelationshipConstruct, 
PaceConstructAttribute, PaceLinkRelPrefix

Specific @rel values (or element names, if PaceReplaceLinkElement is 
adopted): PaceLinkAttrDefaults, PaceLinkConstruct, PaceLinkDelicious, 
PaceLinkParent

Other: PaceLinkPurpose, PaceReplaceLinkElement

Here are two options we could start by choosing between, and the next 
steps that would arise from each.

1) Allow Link Constructs (I'm purposely not saying "the link element" 
both here and below) to point to various sorts of things rather than 
tightening it up as suggested in PaceLinkPurpose -- don't use Link 
Constructs as a "partially understandable" extension point
	* close PaceLinkPurpose, as well as everything listed above under 
"Extensibility", which I don't think has any value without a tighter 
definition of Link Constructs
	* continue discussion of PaceReplaceLinkElement and everything listed 
under "Specific @rel values"

2) Tighten the definition of the Link Construct in a manner akin to 
PaceLinkPurpose
	* refine the language of PaceLinkPurpose and incorporate it
	* close PaceLinkConstruct and PaceLinkParent (the additions proposed 
in both, to refer to atom:entries, should probably be done using 
atom:id, which may not be dereferencable, so they would no longer 
belong in any Link Construct.)
	* continue to discuss PaceReplaceLinkElement, PaceLinkAttrDefaults, 
PaceLinkDelicious, and everything listed under "Extensibility"

The first option simplifies the discussion more, but I think it's the 
wrong way to go.  If we choose the second option, I'd suggest attacking 
the "Extensibility" proposals next while we're still fired up for the 
fight rather than postponing this core question yet again, and leaving 
the other three till after that.  PaceReplaceLinkElement is a similarly 
big question, but I think it will be easier to address after making a 
decision regarding extensibility.