Subject: PaceLinkAttrDefaults

From: Sam Ruby <[email-masked]>
Date: Mon, 19 Jul 2004 13:52:21 -0400

http://www.intertwingly.net/wiki/pie/PaceLinkAttrDefaults

  - - -

Preamble:

   Can you live with

     <link href="uri"/>

   ?

  - - -

Preface:

"Having an element that says, here is a pointer to some data that is 
related to this entry that is too large to fit in the feed is a good 
idea. Similarly providing a hint at what the MIME type is so the reader 
knows whether it can handle that MIME type or can display something 
specific to that media type in the user interface without making an 
additional request to the server is very useful."

Dare Obasanjo, 
http://www.25hoursaday.com/weblog/default.aspx?date=2004-05-26

  - - -

Main text

There is a lot of hyperbole floating around relating to the link tag. 
Let me start of by stating some non-goals:

1) It is a non-goal of the link element to define an extensibility model 
that enables consumers to achieve an almost AI like ability to sense and 
adapt to new constructs that may be introduced at some point in the far 
distant future.

2) It is a non-goal of the link element to make anything more than 
minor, incremental, adaptations over the existing prior art of HTML link 
tags, RSS link tags, and RSS 2.0 enclosure tags.  In particular, it is a 
non-goal to introduce "co-occurence constraints" or a type system.

3) It is a non-goal to make all producers to provide information that 
they don't have, or to make all consumers interpret all link tags 
identically.

  - - -

Now, lets explore what a link tag is in terms of an abstract "schema". 
In relational database terms, a link element when used within a the 
context of an atom entry would be a table:

The first column is id of the entry.  This is a foreign key.

There are five additional columns, rel, type, href, hreflang, and title. 
  Rel has a default of "alternate".  href has a non-null constraint. 
All the remaining elements may be null.

None of these columns are a primary key.

  - - -

Now lets explore usage scenarios.  First from a producer perspective, 
the primary usage would be to declare the permalink associated with this 
entry.  From a syntax perspective, this usage should be optimized for. 
As the type attribute is merely advisory, it should be recommended but 
not be required.  The remaining attributes should only be provided if known.

  - - -

Continuing with a consumer perspective, there are a number of use cases. 
  Identifying the permalink is obviously a key one.  In relational db terms:

   select href from link where entryid='uri' and rel='alternate'

RSSBandit may wish to identifying calendar events, thus:

   select href,title from link where entryid='uri' and type='text/calendar'

Bloglines may with to identify which blog entries reference a given one 
thus:

   select entryid from link where href='uri'

  - - -

 From a syntax perspective, the most common use case is should be able 
to be simply expressed thus:

   <link href="uri"/>

A link blog may want to acknowledge the origin of a given bit of news, thus:

   <link href="uri" rel="via"/>

An event could be indicated thus:

   <link href="uri" rel="event" type="text/calendar"/>

  - - -

Prior art includes the RSS link tag, which variously would be used to 
point to the permalink of the item itself, or to the full story that is 
summarized by the item.

Then there is the HTML link tag, which defines most of the semantics of 
this link tag.

Then there is the enclosure element in RSS 2.0 that, while perhaps 
misnamed, does a reasonably good job - with one exception, first noted 
by Dare.  Outside of the specification itself, an expectation was set 
that an enclosure was to be automatically downloaded asynchronously; 
enough so that it impeeded other use cases.

  - -

Summary:

The purpose is not to make things automagically happen.  There is no 
pixie dust.  The purpose it so enable a small bit of loose coupling. 
Producers provide what information that they have available.  Consumers 
select what they recognize, and ignore the rest.

  - - -

Impacts: existing producers may want to take advantage of the new 
defaults.  Consumers will have to deal appropriately with the new defaults.

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 19 Jul 2004 11:46:14 -0700 (PDT)

The suggestions in the Pace seem fine to me. 

Personally I'd rather see a Pace that once and for all
states that the link tag isn't extensible or if it one
that provides guidelines for its usage if it is...

Oh, it looks likes there is PaceLinkPurpose which is a
decent start.  

--- Sam Ruby <[email-masked]> wrote:
> defaults.  Consumers will have to deal appropriately

=====
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/

---

From: Graham <[email-masked]>
Date: Mon, 19 Jul 2004 14:54:48 -0400

On 19 Jul 2004, at 1:52 pm, Sam Ruby wrote:

> Bloglines may with to identify which blog entries reference a given 
> one thus:
>

I can't see either of these being useful without either:
a) Assuming links only ever contain certain kinds of links - ie There's 
never going to be 
rel="This-link-is-completely-unrelated-to-the-entry-please-ignore", or 
equivalent (I assure you there will be values that mean as good as 
that).
b) Only selecting certain link types. I assure you RSSBandit would do 
well to add "and rel='related' ".

Seeing as that's the core of your proposal, a big fat -1 from me.

Graham

(PS Show us your extensibility mechanism)

---

From: Sam Ruby <[email-masked]>
Date: Mon, 19 Jul 2004 14:53:30 -0400

> Oh, it looks likes there is PaceLinkPurpose which is a

I agree that PaceLinkAttrDefaults is incomplete without resolving this 
question.

I also think that some version of the prose that I submitted to the 
email list (in particular, the listing of non-goals) should be captured 
in some form - either informative text, or in a companion Usage Guide.

- Sam Ruby

---

From: Sam Ruby <[email-masked]>
Date: Mon, 19 Jul 2004 15:22:01 -0400

Graham wrote:

> equivalent (I assure you there will be values that mean as good as that).

The core of the proposal is that different consumers will chose to 
ignore different things.  It is inconceivable to me that anybody would 
put a link inside of an entry with the intent that it be completely 
unrelated to the entry and ignored by literally everyone.

The intent of the proposal is to allow for what the enclosure element 
almost - but doesn't completely - provide: namely a bit of loose 
coupling.  Bloglines, for example, would not have to understand the 
value of the rel attribute in order to identify which blog entries 
reference this one.  rel could be "related", "via", or 
"in-refutation-of" for all such an application could care.

Once we nail down the general shape of the solution, we can proceed to 
decide what the permissable values of the rel attribute are.  At the 
moment, I'm leaning towards expelling a number of the current 
definitions (e.g., service.*), nailing down a few values (alternate 
being the key one), and establishing a registration scheme for new 
values.  Hopefully the registration scheme will be hairy enough to scare 
away fivilous and unproven suggestions.  Hmmm, seems to me like IANA 
might fit that bill.

- Sam Ruby

---

From: Graham <[email-masked]>
Date: Mon, 19 Jul 2004 15:46:53 -0400

> unrelated to the entry and ignored by literally everyone.

I didn't mean that literally. My point was that not paying attention to 
the rel value doesn't seem safe from a not-displaying-nonsense point of 
view.

> "in-refutation-of" for all such an application could care.

One example from HTML I'm thinking of is rel="stylesheet". I'm not sure 
what the syndication equivalent of that would be, but if Bloglines were 
to include such things in its list of popular links, it would obviously 
run in to trouble.

> At the moment, I'm leaning towards expelling a number of the current 
> values.

If you can make <link> itself have a semantic meaning, and @rel just be 
further information, I might be OK with it. It'd probable make sense 
for all allowable values to be some variation on "related". "alternate" 
actually looks like it doesn't belong (I note you didn't include it in 
your Bloglines example above). As long as we stop crow-baring 
everything that's a URI (which on the internet = everything) into one 
element, I'm happy.

Graham

---

From: Ken MacLeod <[email-masked]>
Date: 19 Jul 2004 16:37:54 -0500

Sam Ruby <[email-masked]> writes:

> Hopefully the registration scheme will be hairy enough to scare away
> fivilous and unproven suggestions.  Hmmm, seems to me like IANA
> might fit that bill.

Using element names appears to be hairy enough to scare away frivious
and unproven suggestions, also.

When PaceLinkAttrDefaults describes its method of extension, we can
compare it more evenly with PaceReplaceLinkElement.

+1 in principle on the goals, non-goals, and summary.

Earlier,
> minor, incremental, adaptations over the existing prior art of HTML
> link tags, RSS link tags, and RSS 2.0 enclosure tags.  In
> particular, it is a non-goal to introduce "co-occurence constraints"
> or a type system.

In the notes of the Pace, it indicates that <atom:link> would be a
type that means "GET" links, and supporting PaceServiceElement for
links that are of type "service".  If that's the intent, is this truly
a non-goal?

  -- Ken

PS. In case it was missed in an earlier post, I am no longer
supporting discoverable or explicit link types.

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 19 Jul 2004 14:42:44 -0700 (PDT)

--- Sam Ruby <[email-masked]> wrote:
> decide what the permissable values of the rel
> attribute are.  
> At the 

This implies to me that PaceLinkPurpose and its ilk
should be the focus of discussion before we bother
with related Paces like PaceLinkAttrDefaults. 

=====

---

From: Antone Roundy <[email-masked]>
Date: Mon, 19 Jul 2004 16:13:26 -0600

> compare it more evenly with PaceReplaceLinkElement.

I just took a look at PaceReplaceLinkElement, and it doesn't describe 
it's method of extension either.  I was going to follow that sentence 
with assumptions and ask if they were correct, but a few possibilities 
come to mind, so instead, I'll save myself the trouble of typing them 
all up and just ask, what is PaceReplaceLinkElement's method of 
extension?

---

From: Ken MacLeod <[email-masked]>
Date: 19 Jul 2004 17:24:42 -0500

Antone Roundy <[email-masked]> writes:

> > When PaceLinkAttrDefaults describes its method of extension, we
> > can compare it more evenly with PaceReplaceLinkElement.
> 
> I just took a look at PaceReplaceLinkElement, and it doesn't
> describe it's method of extension either.  I was going to follow
> that sentence with assumptions and ask if they were correct, but a
> few possibilities come to mind, so instead, I'll save myself the
> trouble of typing them all up and just ask, what is
> PaceReplaceLinkElement's method of extension?

The same as other extensions in Atom: a new element name.

  -- Ken

---

From: Tim Bray <[email-masked]>
Date: Mon, 19 Jul 2004 15:42:47 -0700

> http://www.intertwingly.net/wiki/pie/PaceLinkAttrDefaults

+1 to <link href=""> for the permalink.

+1 to the proposed semantics for type=""

+1 to removing rel= from current drafts until we have a coherent 
proposal on the table (if someone thinks that there's an existing Pace 
worth serious consideration, point it out)

+1 to removing the service.* machinery from <link> to its own element

  -Tim

---

From: Ken MacLeod <[email-masked]>
Date: 19 Jul 2004 17:55:50 -0500

Tim Bray <[email-masked]> writes:

> proposal on the table (if someone thinks that there's an existing
> Pace worth serious consideration, point it out)

PaceReplaceLinkElement.

  -- Ken

---

From: Antone Roundy <[email-masked]>
Date: Mon, 19 Jul 2004 17:32:45 -0600

> The same as other extensions in Atom: a new element name.
Okay, that much was obvious.  You've posted a similar comment in  
PaceLinkPurpose.  Here are a few comments and assumptions on each:

PaceReplaceLinkElement:
1) How new links are defined: Whether in the core or a new namespace,  
new Link Constructs get a new element name.
2) Name collision: Because extensions have to use their own namespace,  
there's no problem with name collision.
3) Default Link Construct processing for unknown types: Apparently none  
(not all Link Constructs can be handled the same way, so it seems  
unlikely that new Link Constructs will all follow any particular  
pattern).
4) Unknown Link Construct recognizability: Unknown, but not useful  
anyway because of the answer to #3.

PaceLinkAttrDefaults:
1) How new links are defined: add new @rel value to the core  
specification (currently enumerated in the API spec)
2) Name collision: Because extensions can't create new @rel values,  
there's no problem with name collision.
3) Default Link Construct processing for unknown types: Unless other  
proposals like PaceLinkPurpose and PaceServiceElement are adopted,  
apparently none for the same reasons as listed for  
PaceReplaceLinkElement.  (Note: Sam's comment in the Notes section  
supports something along those lines).
4) Unknown Link Construct recognizability: The link element is the only  
Link Construct, so it's immediately recognizable, but that may or may  
not be useful depending on what happens with #3.

PaceLinkPurpose:
1) How new links are defined: New @rel values are added to the core, or  
by some not-yet-specified extension method.
2) Name collision: Unknown (see #1).
3) Default Link Construct processing for unknown types: Unknown link  
types can be rendered as user-activatable links.
4) Unknown Link Construct recognizability: The link element is the only  
Link Construct, so it's immediately recognizable.

Other comments:
A) If only this section of PaceLinkPurpose is adopted:
> 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:
and not this part:
> 3.4.1 "rel" Attribute The "rel" attribute indicates the type of  
> relationship that the link represents. Link constructs MUST have a rel  
> attribute, whose value MUST be a string, and MAY either be one of the  
> values enumerated (either "below:", if we move the list into this  
> specification, or "in the Atom API specification  
> <eref>http://bitworking.org/projects/atom/draft-gregorio-09.html</ 
> eref>." otherwise) or be defined by an extension.
and additions to the @rel list are only allowed in the core (not  
through extensions--as at present), then #1 and #2 for PaceLinkPurpose  
become the same as for PaceLinkAttrDefaults.

B) If section 3.4 from PaceLinkPurpose is adopted and  
PaceReplaceLinkElement is adopted (except that things like service-post  
which don't work with PaceLinkPurpose are no longer considered "Link  
Constructs"), then answers for the combination come from #1 and #2 from  
PaceReplaceLinkElement, and #3 and #4 from PaceLinkPurpose.

C) If we can decide on a way to recognize Link Constructs and adopt  
section 3.4 from PaceLinkPurpose, I would support  
PaceReplaceLinkElement to the extent that it is compatible with  
PaceLinkPurpose.  That would answer #1 and #2 for PaceLinkPurpose.  The  
difficult part is deciding how to make Link Constructs recognizable.   
Of the ideas mentioned thus far, I think the least potentially  
problematic is to have a separate namespace for Link Construct  
attributes, the use of which indicates that the element using them can  
be processed as a Link Construct.  For example:

<feed xmlns="atom's namespace"
	xmlns:ex="atom's extension namespace"
	xmlns:ox="some other extension's namespace">

<some-core-link-construct ex:href="uri" ... />

<ox:some-extension-link-construct ex:href="uri" ... />

</feed>

---

From: Antone Roundy <[email-masked]>
Date: Mon, 19 Jul 2004 17:47:11 -0600

Note a few additions to the following:

> <ox:some-extension-link-construct ex:href="uri" ... />

<ox:some-core-NON-link-construct href="uri" ... />
<ox:some-core-NON-link-construct ox:href="uri" ... />

<ox:some-extension-NON-link-construct href="uri" ... />

> </feed>

Only @ex:href indicates a "Link Construct" as defined by 
PaceLinkConstruct.  @href and @ox:href do not.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 20 Jul 2004 11:11:43 +1000

> All the remaining elements may be null.

I'm not so sure about @rel defaulting to "alternate". Does that capture the
essence of "here is a link to a resource of some relevance to this entity"?

Perhaps the default should be null, meaning no relationship is specified,
only the connection is specified.

I'm thinking particularly of <link> inside <author>.

e.

---

From: Ken MacLeod <[email-masked]>
Date: 19 Jul 2004 21:47:28 -0500

> PaceLinkPurpose.  Here are a few comments and assumptions on each:

Comparison matrix copied to LinkReferences -- excellent work!

[updated from followup message]
> PaceLinkPurpose.  That would answer #1 and #2 for PaceLinkPurpose.
> The difficult part is deciding how to make Link Constructs
> recognizable.  Of the ideas mentioned thus far, I think the least
> potentially problematic is to have a separate namespace for Link
> Construct attributes, the use of which indicates that the element
> using them can be processed as a Link Construct.  For example:
> 

Yes, PaceReplaceLinkElement can modified to support link types.
@atom:href for human clickable links and @atom:service for service
links would work.  New link types are also extensible using XML
namespaces.

However, first we have to come to consensus on what link types are (or
what types we're only interested in) and whether we want to encode
link types.

Dare and Graham have said that they won't implement link types, they
will look at each relation by name to determine client action.
However, Graham might be ok with a human-clickable link type.

Sam says that link types are a non-goal, but then he might support
human-clickable and service link types.

Tim said we shouldn't do types but then says he supports
human-clickable and service link types.

Norm seems to be favoring many tightly clustered link types with @rel
values.

PaceLinkPurpose defines a human-clickable link type and indicates
other elements (PaceServiceElement) should be used for other link
types.

Regardless of link types, there are many people who say they favor
element names for the relation name.

I'm neutral on speccing link types.  I can see how they can be useful
in generic processing, yet I can see the benefit of being concrete on
a link-name basis.  For either type or name, I'm a little more in
favor of XML Namespace extension, which we already have, over IANA
registration.

So, it seems like we're choosing between these:

1) No link types, IANA registration of relation name (@rel):

    <link rel="via" type="text/html" uri="URI"/>
    <link rel="alternate" type="text/html" uri="URI"/>
    <link rel="service.edit" type="application/atom+xml" uri="URI"/>
    <link rel="image.favicon" type="image/png" uri="URI"/>
    <link rel="extension.name" type="text/anything" uri="URI"/>

2) No link types, qnames for relation name (element name):

    <via type="text/html" uri="URI"/>
    <alternate type="text/html" uri="URI"/>
    <edit type="application/atom+xml" uri="URI"/>
    <favicon type="image/png" uri="URI"/>
    <extns:name type="text/anything" uri="URI"/>

3) Link types, qname for link type (element name), IANA registration
   of relation name (@rel):

    <link rel="via" type="text/html" uri="URI"/>
    <link rel="alternate" type="text/html" uri="URI"/>
    <service rel="edit" type="application/atom+xml" uri="URI"/>
    <image rel="favicon" type="image/png" uri="URI"/>
    <extns:type rel="name" type="text/anything" uri="URI"/>

4) Link types, qname for link type (URI attribute), qname for relation
   name (element name):

    <via type="text/html" atom:href="URI"/>
    <alternate type="text/html" atom:href="URI"/>
    <edit type="application/atom+xml" atom:service="URI"/>
    <favicon type="image/png" atom:uri="URI"/>
    <extns:name type="text/anything" extns:type="URI"/>

PaceLinkPurpose and PaceServiceElement are (3), PaceLinkAttrDefaults
is currently (1) but could be (3), PaceReplaceLinkElement is currently
(2) but could be (4).  PaceExtensionNamespace (just posted) appears to
be (4).

Note that the (4) example has a "generic" link type (atom:uri) case
which is "no link type" so only the relation name has significance.

  -- Ken

---

From: Graham <[email-masked]>
Date: Tue, 20 Jul 2004 01:55:58 -0400

> worth serious consideration, point it out)

PaceReplaceLinkElement was intended to be the first step out of the 
@rel quagmire, because it doesn't immediately change any functionality. 
The problem we have now is that everything is tangled up inside one 
element, and it's very hard to make changes because everyone's Paces 
are overlapping. If we can get everything into separate elements, we 
can consider each one separately and make changes, even if it's just to 
come up with a new grouping scheme.

(re: PaceLinkAttrDefaults itself, I think rel="alternate" is a special 
case. rel="related" should be the default and rel="alternate" should be 
moved to a separate element entirely)

Graham

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 20 Jul 2004 05:42:42 -0700 (PDT)

>     <link rel="extension.name" type="text/anything"

I like this idea since the number of link types will
be sufficiently reduced to make it feasible to deal
with. Of course, then I don't see why anyone would go
through the trouble of creating a link type when they
could just create their own namespaced element. 
 
>     <extns:name type="text/anything" uri="URI"/>

I'm not sure what this means. It seems you are saying
that there will be a number of elements that have a
uri and type attribute but besides that there is no
explicit or implicit relationship between them. If so,
I like this idea as well although it may cause people
to see a pattern where none exists. 

>     <extns:type rel="name" type="text/anything"

I'm not sure what the point of differentiating this
from (1). To me what is key is either making all links
in a particular types have uniform semantics or
setting the bar high for creating new link classes. 

The above is an in-between that doesn't seem
necessary. An <image> link type isn't very useful
since the behavior of a client on rel="favicon" vs.
rel="logo" is very different. This is just fragmenting
the <link> element without adding clarity. 

So the main benefit of this approach would then be
IANA registration of rel values. Then why bother
having link types.

>     <extns:name type="text/anything"

-1 

This combines the worst characteristics of all the
aforementioned approaches. 

=====

__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo