Subject: PaceLinkPurpose

From: Antone Roundy <[email-masked]>
Date: Fri, 16 Jul 2004 10:17:20 -0600

Well, here we go.  This is either going to be fun or painful.  I for 
one am optimistic that it will be fun--that we'll finally resolve the 
link/@rel vs. various link constructs issue.

Taking the "Key Questions" section of PaceLinkPurpose as a starting 
point:

> 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?

My current thinking is that I'd be happy with either link/@rel or 
various Link Constucts (and no @rel) as long as Link Constructs are 
recognizable, so that they can be used for extensibility.  If we go 
either of those directions, I'd definitely advocate adopting the 
following spec text from the Pace, or something substantially similar:

> 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. When accessing 
> the resource pointed to by the href attribute using HTTP, the GET 
> method MUST be used. It MUST NOT have any child content. The Link 
> Construct has the following attributes:

If we dump link/@rel and DON'T specify some way to recognize unknown 
Link Constructs, then I DON'T think the limitations of that text are of 
much value.

I think the core question that precedes all others is whether Link 
Constructs are going to be used for extensibility.  If yes, the second 
question is whether to use link/@rel with an open @rel list or whether 
to have multiple Link Construct elements which are all recognizable as 
Link Constructs in some way.  If link/@rel, the third question is how 
extensions will specify their @rel values; otherwise, how to recognize 
Link Constructs defined in extensions.  Once those questions are 
settled, it should be relatively easy to hammer out a list of either 
@rel values or Link Construct elements to include in the core spec.

Antone

---

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

> @rel values or Link Construct elements to include in the core spec.

I agree that that is the core question, but I think we can't answer that 
question separate from hammering out the specification language.

- Sam Ruby

---

From: Antone Roundy <[email-masked]>
Date: Sat, 17 Jul 2004 10:42:56 -0600

> link/@rel vs. various link constructs issue.
My optimism has waned slightly, but let's keep going.

A question for those who don't see a useful extensibility path in this 
discussion, just to be sure I understand your POV: do you believe that 
useful extensibility using link/@rel is not possible; that useful 
extensibility is not possible using Link Constructs; that useful 
extensibility is not possible with link-like things, whether Link 
Constructs or otherwise; that useful extensibility is simply not 
possible at all; or something else?

I guess I should say something about what I mean by useful 
extensibility--the ability to make useful decisions about how to handle 
elements that one doesn't fully understand.

---

From: Graham <[email-masked]>
Date: Sat, 17 Jul 2004 13:03:22 -0400

On 17 Jul 2004, at 12:42 pm, Antone Roundy wrote:

> do you believe that useful extensibility using link/@rel is not 
> possible;

Yes. There are no practical proposals on the table. By which I mean, 
inventing our own namespace system for attribute values is a 
non-starter, especially when we should be using XML's own namespace 
system.

> that useful extensibility is not possible with link-like things, 
> whether Link Constructs or otherwise; that useful extensibility is 
> simply not possible at all; or something else?

I wouldn't say it's impossible, just not a worthwhile goal given the 
tradeoffs.

Graham

---

From: Dare Obasanjo <[email-masked]>
Date: Sat, 17 Jul 2004 10:20:47 -0700 (PDT)

> elements that one doesn't fully understand.

I haven't seen a proposal yet that defines a feasible
extensibility mechanism. I don't think using link/@rel
by themselves are feasible as an extensibility
mechanism unless their scope is narrowed and usage is
strictly defined.

I agree with Tim Bray that defining this properly
would be akin to defining a type system of sorts if
multiple classes of link types are to be supported. 

=====
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!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/