Subject: atom:link state of play

From: Tim Bray <[email-masked]>
Date: Wed, 13 Oct 2004 17:35:24 -0700

I have just read all the link-related Paces, both those currently on 
the Public Issues List and the various guerilla offerings that have 
been provoked by the discussion, and then I ran through the mailing 
list archive again.

My overview of the state of play, which anyone should feel free to 
correct if it's wrong:

1. Pace Statuses

The following Paces have been convincingly shouted down and should be 
closed
  PaceLinkAttrDefaults
  PaceLinkRelMechanism (ouf, I think this set a record in the -1 count, 
and I didn't even get around to putting my -1 in)

The following Paces are clinging to life, have a single -1 but aren't 
being strung up to the rafters by a howling mob:

  PaceLinkConstruct (adds rev="comment|update|replaces")
  PaceLinkDelicious (add "related" and "about" to @rel values)
  PaceLinkParent (add "in-reply-to" to @rel values)
  PaceReplaceLinkElement (no @rel, <atom:prev>, <atom:alternate>, 
<atom:next>, etc...)

The following Pace has, I think, a certain amount of positive buzz, 
with some +1's and some comments saying "OK, but improve it this way or 
that":

  PaceLinkPurpose

2. Service Attributes

There's a PaceServiceElement out there that takes the service.this and 
service.that out of the repertoire of @rel and adds <atom:service 
type=""> or some such, and it's got enough +1's that I was convinced it 
had already been accepted, but I guess not.  But I bet it will be, so 
it might be reasonable to omit the service.* values in discussion of 
@rel possibilities.

3. atom:link omission

Asbjørn posted PaceOptionalAlternateLink which proposes to make 
atom:link optional.  Sam Ruby proposed a variant where it's optional 
unless <atom:content> isn't there, in which case it's required.  Not 
relevant in the short term, but my spidey-sense tells me these will 
probably get accepted, because we went over this in the mailing list 
some time ago and there wasn't much pushback.

4. Extensibility

Ladies and gentlemen, this is a horrible mess!

The following mechanisms are on the table for an extensible link 
construct:

1. @rel values from keyword list hardwired in the spec (current draft)
2. @rel values have prefixes from an IANA registry 
(PaceLinkRelPrefixReg)
3. @rel values are qnames (PaceLinkRelMechanism)
4. @rel values are URIs (PaceLinkRelUri)
5. anything with an atom:href attribute is a link 
(PaceRelationshipConstruct)
6. a general construct-signaling mechanism (PaceConstructAttribute).  
[Steve Newcomb, where are you?  This idea is at least 15 years old, 
it's called "Architectural Forms" and is an ISO Standard, see Annex A 
of ISO 10744]
7. Invent a new element for each type of link (PaceReplaceLinkElement)

It is painfully obvious that there is no consensus on how to do 
extensibility.

Furthermore, it is painfully obvious that there is no consensus as to 
what basic flavors of link, if any, should be cooked into the spec (or 
the IANA registry, or given well-known URIs, or whatever).

Furthermore, I challenged the WG 
(http://imc.org/atom-syntax/mail-archive/msg10471.html) as to whether 
we really had to do extensible generalized links.   It got one solid 
"yes" from Danny Ayers (but Rob Sayre pushed back hard), one 
sort-kinda-yes from Dare Obsanjo ("I'm partial to allowing some form of 
extensibility in link constructs IFF a clear and concise definition of 
what it means to be 'link' makes it into the spec.") and one 
interesting counter-proposal from Sayre 
(http://imc.org/atom-syntax/mail-archive/msg10481.html) which I don't 
think is a Pace yet.

5. Conclusion

SO, if I had to make consensus call right now based on where we are 
right now, it would be based on "what's left over after you remove 
everything that's been objected to" and it would look something like:

  1. The only defined value for @rel on atom:link would be "alternate" 
and that would be the default
  2. the material would be moved from the protocol to the format draft
  3. The service.* stuff would go into a different element or set of 
elements
  4. atom:link would be omissable (maybe required if atom:content isn't 
there)

6. Recommendations

People who want some sort of an extensible link framework REALLY NEED 
to go off in a corner and agree on a recipe and see if they can build 
consensus around one thing.  I would also point out that if it's not in 
Atom 1.0, well, it could be added later.

Also, I think Rob Sayre's extensibility idea needs to be cooked into a 
Pace.

  -Tim

---

From: Antone Roundy <[email-masked]>
Date: Wed, 13 Oct 2004 19:11:03 -0600

> being strung up to the rafters by a howling mob:
...
>  PaceLinkDelicious (add "related" and "about" to @rel values)
I'll give this a +1.

> 2. Service Attributes
>
> ... PaceServiceElement ... I was convinced it had already been 
> accepted, but I guess not.
I thought it had been too...perhaps based on the fact that it's in the 
"accepted" part of the issues list.  Did it get moved there 
accidentally?

> 4. Extensibility
...
> sort-kinda-yes from Dare Obsanjo ("I'm partial to allowing some form 
> of extensibility in link constructs IFF a clear and concise definition 
> of what it means to be 'link' makes it into the spec.") and one 
I'm with Dare on this one.  From time to time, people come up with 
ideas for new @rel values, some of which don't (assuming 
PaceLinkPurpose) don't belong in <link>, but some of which do and would 
be useful.  I think the probability of people coming up with other good 
ideas is high enough that building extensibility in would be good...as 
long as we tighten the definition of Link Constructs.

---

From: Robert Sayre <[email-masked]>
Date: Wed, 13 Oct 2004 21:21:03 -0400

> Also, I think Rob Sayre's extensibility idea needs to be cooked into a 

I have too many pans in the fire right now, so I asked Danny to help me 
get it started. He agreed, so we are working a notion of properties and 
reexamining GRDDLish stuff in the process.

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Thu, 14 Oct 2004 11:55:12 +1000

On 14/10/04 10:35 AM, "Tim Bray" <[email-masked]> wrote:

> we really had to do extensible generalized links.

I don't know how I missed that. I've been a proponent for allowing
exstensibility in link @rel from the beginning and I've been coming up with
new @rel values as a side effect of other discussions.

Just yesterday I wrote

    <link rel="playlist" type="application/atom+xml" href=... />

where, of course, "playlist" could be "ns:playlist", "prefix.playlist", or
whatever according whichever extensibility model we go with.

other @rel values which are not in the core list of enumerated types include

    comments
    versions
    trackbacks
    pings
    components
    licence
    prefetch

and probably some others I've forgotten about.

The point is that very few of these were in the original enumerated list.
They were thought up after the fact. Limiting link/@rel to an known set
would stifle innovation in this form.

e.

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 13 Oct 2004 19:19:29 -0700 (PDT)

> other @rel values which are not in the core list of

A bunch of link types with disimilar semantics. Unless
there's a clearly defined mechanism for telling
clients how to distinguish between the various link
types or a reasonable default behavior can be picked
for ALL links I don't see how this is any better than
allowing namespaced extension elements. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #23
I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks.

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

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 13 Oct 2004 19:49:31 -0700

>would stifle innovation in this form.

Would you (and others) be happy with a simple IANA registry that gets 
filled in when there is a standards-track RFC. It would start with 
"alternate -> RFC {ournumber}", and entries would be added as the 
RFCs issued. FWIW, it would be perfectly permissible for a single RFC 
to be the registration for multiple new values.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Antone Roundy <[email-masked]>
Date: Wed, 13 Oct 2004 20:59:54 -0600

> allowing namespaced extension elements.
I can conceive of comments, versions, trackbacks, pings and maybe 
license being handled quite similarly (on click/select/whatever, 
display another newsfeed or a web page), though I'd have to see 
definitions of them to be sure they mean what I think they mean.  I 
have no idea what is meant by components, so have no comment on that.  
Prefetch seems ... a little out of place.  Not that an element with 
that purpose is necessarily a bad idea, but it doesn't fit my mental 
model of a Link Construct.

---

From: Antone Roundy <[email-masked]>
Date: Wed, 13 Oct 2004 21:18:41 -0600

On Wednesday, October 13, 2004, at 08:49  PM, Paul Hoffman / IMC wrote:
> "alternate -> RFC {ournumber}", and entries would be added as the RFCs 
> issued. FWIW, it would be perfectly permissible for a single RFC to be 
> the registration for multiple new values.

Adding this to the list of proposals and restating it in terms of 
difficulty of adding new values, we have:

1) Impossible: the list is closed (actually, this is not proposed)
2) Extremely difficult: get it added to the Atom core spec
3) Quite difficult: get it into an RFC
4) Troublesome: register each value
5) Bothersome but doable: register a prefix
6) Easy: make your own extension

I think I might be satisfied by #3, with the following conditions and 
reason:

Conditions:
1) The Atom WG's charter is extended ("Extension development is not 
included in this charter.") to cover ongoing discussion of proposed 
additions.  Otherwise, I think "quite difficult" would turn into 
"extremely difficult" or worse.
2) The definition of a Link Construct is tightened (otherwise, I much 
don't care what else happens with it)

Reason: Unless people coming up with new @rel values have a tight 
definition of a Link Construct firmly in mind, it's not unlikely that 
people will create new values which don't fit the definition that...I 
hope we come up with.  If that happens, Link Constructs as an 
extensibility point could become useless.  It may be that "market" 
forces would kick things in line (if aggregators process extension 
links in a standard way, and refuse to make exceptions for things that 
don't belong there), but I'm not sure we can count on that.  So there 
needs to be SOME barrier.  It's just a question of how high it should 
be.

I think I may be arguing against a few of my own proposals here...

---

From: Antone Roundy <[email-masked]>
Date: Wed, 13 Oct 2004 21:22:38 -0600

> the registration for multiple new values.
One more thing--there's an argument for not setting the bar too high: 
if it is too difficult to get new values officially recognized, we run 
the risk of people making up new values without going through the 
process.  For this reason, it may be best to devise a mechanism that 
ensures (as much as possible) that we don't get naming collisions.  
What a dilemma.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 13 Oct 2004 20:48:51 -0700

At 9:18 PM -0600 10/13/04, Antone Roundy wrote:
>I think I might be satisfied by #3, with the following conditions and reason:
>
>Conditions:

We don't need to extend the Atom charter to do this, and in fact such 
an extension probably wouldn't happen. Typically in the IETF, mailing 
lists live long after the WG is closed down. If the IESG gets a 
proposal for a standards-track RFC with a new @rel value, the Apps AD 
will probably ping the list and say "Have you folks discussed this? 
Is it OK?"

>2) The definition of a Link Construct is tightened (otherwise, I 
>much don't care what else happens with it)

That's *always* a good idea. And your proposed text is...

>One more thing--there's an argument for not setting the bar too 
>high: if it is too difficult to get new values officially 
>recognized, we run the risk of people making up new values without 
>going through the process.  For this reason, it may be best to 
>devise a mechanism that ensures (as much as possible) that we don't 
>get naming collisions.  What a dilemma.

It's one we fight with in the IETF all the time. A standards-track 
RFC is probably a reasonable bar because the extension has to come up 
with a clear description of what you are supposed to do with the 
link; that kind of description easily fits into a standards-track 
RFC. I think of these like ESMTP extensions, of which there are many.

--Paul Hoffman, Director

---

From: Eric Scheid <[email-masked]>
Date: Thu, 14 Oct 2004 15:09:43 +1000

> allowing namespaced extension elements.

they all have the same generic semantic: here is a resource which is related
to the current entry, click the link to retrieve the resource.

saying they have dissimilar semantics is like claiming the <a> element in
html is also broken because I could link to an RSS feed, a jpeg image, a
quicktime movie, another html page, a gopher page, an ftp site, and SVG
graphic, etc etc etc. Each one could be treated differently, but each one
also has the same basic semantic.

e.

---

From: Eric Scheid <[email-masked]>
Date: Thu, 14 Oct 2004 15:42:21 +1000

On 14/10/04 12:59 PM, "Antone Roundy" <[email-masked]> wrote:

> I can conceive of comments, versions, trackbacks, pings and maybe license
> being handled quite similarly (on click/select/whatever, display another
> newsfeed or a web page), though I'd have to see definitions of them to be sure
> they mean what I think they mean.
> 
"comments" would be defined as being "here is a resource of comments on this
entry", and it would depend on the mime-type of the resource as to what
exactly happens next. If it is "text/html" you know it's a web page, if it
is "application/pdf" you can punt the retrieved resource to your PDF viewer
plugin/application, if it is "application/atom+xml" you could display the
feed of comments in the aggregator itself and even offer to subscribe to
that feed.

Similarly versions, trackbacks, pings.

License would be a link to a resource describing the license for the entry,
whether it's a CC license page, or a GNU license page, or whatever.

(I can see however that these definitions are not entirely obvious: someone
somewhere is likely to interpret "comments" as meaning "here is a service
point for submitting comments")

> I have no idea what is meant by components, so have no comment on that.

While discussing play lists it struck me that some folks might want to
provide a list of components for any given mp3, such that others might then
take those components and re-mix them. That list could be in any format, not
just atom. See the @type attribute to determine.

Thus one entry which is discusses "Violin Concerto in D major, Opus 77,
Second Movement" could have a link to another atom feed document in which
each entry is a different instrument.

Also, one entry which is an alternate for a 200 page PDF could have a
components link in which each entry is an alternate for each of the chapters
of that PDF. Download the whole monolithic thing, or dig a little deeper and
retrieve an atom feed document which summarises each chapter and offers
links to smaller PDFs.

> Prefetch seems ... a little out of place.  Not that an element with that
> purpose is necessarily a bad idea, but it doesn't fit my mental model of a
> Link Construct.

By itself it doesn't make a lot of sense. But if you had an @rel with
"transcription prefetch" (and @type="application/mpeg") you'd know that the
publisher has indicated they don't mind if you prefetch that resource
(whether prefetching occurs off peak, or simply initiates immediately on
display of the individual entry).

In the same class as "prefetch" you could also have other relationship
modifiers, like votes [1] or authority qualifiers (like 'factchecked',
'second-sourced', 'rumor' [2]), or a richer set of qualifies such as
discussed in the hypertext community [3].

One important note: these are advanced uses of the @rel attribute, which
might scare some folks. Remember though that the fall back position is that
a user-agent is free to ignore any @rel value it doesn't recognise.

e.

[1] http://developers.technorati.com/wiki/VoteLinks
[2] made up on the spot right now, so usual caveats apply
[3] http://www.eastgate.com/HypertextNow/archives/Trigg.html

---

From: Eric Scheid <[email-masked]>
Date: Thu, 14 Oct 2004 15:45:19 +1000

> ensures (as much as possible) that we don't get naming collisions.

I thought your #5 hit the mark regarding this point.

> 5) Bothersome but doable: register a prefix

At least this way if people don't bother with registering their prefix then
the scope of name clashes is only with prefixes, not the full set of @rel
values.

e.

---

From: Antone Roundy <[email-masked]>
Date: Thu, 14 Oct 2004 07:52:56 -0600

On Wednesday, October 13, 2004, at 11:42  PM, Eric Scheid wrote:
>> that
The thing is, "prefetch", "factchecked"...don't describe the 
relationship between the entry and the other resource.  One is a hint 
about how to handle the resource, or a note about the FEED publisher's 
intentions regarding the resource (BTW, a link to an MP3, for example, 
might not be published by the publisher of the MP3, so whether they 
mind if it's prefetched or not might not be an appropriate bit of info 
to communicate), and the others are metadata about the link target, not 
the relationship between them.  This kind of information belongs 
somewhere other than @atom:rel.  "vote-for", "vote-abstain", 
"vote-againt" would be reasonable @rel values, though I don't think 
they belong in the core.

---

From: Lance Lavandowska <[email-masked]>
Date: Thu, 14 Oct 2004 11:40:18 -0500

If anyone is interested in the opinions of a rather 'naive
observer'[1] see comments/votes inline:

>   PaceLinkConstruct (adds rev="comment|update|replaces")

-0

>   PaceLinkParent (add "in-reply-to" to @rel values)

+1 to these two

>   PaceReplaceLinkElement (no @rel, <atom:prev>, <atom:alternate>,

A guarded +1, concerned this could go too far.

> it might be reasonable to omit the service.* values in discussion of

I also thought this was accepted: +1

> 7. Invent a new element for each type of link (PaceReplaceLinkElement)

Half of these I just don't understand (I don't have *that* much time
for reading all the background info) and the other half seem like
quibbling over semantics to me.  #7 scares me a bit with the potential
for element explosion.

I'm tending to side with allowing anything in there, let the clients
sort it out (ignore what they don't understand or make it a link,
whatever).  Then see what real-life usage looks like.  Waffle.

Lance 

[1] definition of 'naive observer': I haven't written an aggregator or
client of any sort.  I've "implemented" a feed generator through
copy-paste, though I read the spec first.  I wrote a pre-alpha
implementation of the atom-api in Java (last year).  I try to keep up
with the discussions on this list but often fail.  I don't have the
time to read every Pace nor any of the backing theory/RFCs.

---

From: Graham <[email-masked]>
Date: Thu, 14 Oct 2004 18:27:16 +0100

On 14 Oct 2004, at 1:35 am, Tim Bray wrote:

>  PaceReplaceLinkElement (no @rel,

Pardon? That's the point of it.

> <atom:prev>, <atom:alternate>, <atom:next>, etc...)

Well that's because they were missing from the most comprehensive list 
I could find at the time.

Graham

>  The only defined value for @rel on atom:link would be "alternate" and 
> that would be the default

I propose that "alternate" is a very special case and shouldn't be 
mixed in with other types of link, which ever proposals we adopt.

Graham

---

From: Tim Bray <[email-masked]>
Date: Thu, 14 Oct 2004 10:30:28 -0700

> the registration for multiple new values.

I could go for this, only the registry should have more than one 
initial value.  I would ruthlessly refuse any "would-be-nice" values 
and accept only things that have been very widely deployed and used 
already .

Specifically: "alternate", "about", and "attachment".

And if we *can't* get consensus on this list, I say the hell with it, 
just have an <atom:link> with no @rel, used for what we now call 
rel='alternate', and leave the rest for extensions.  -Tim

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 14 Oct 2004 11:17:16 -0700

>Specifically: "alternate", "about", and "attachment".

Those three work for me.

--Paul Hoffman, Director

---

From: Antone Roundy <[email-masked]>
Date: Thu, 14 Oct 2004 12:56:40 -0600

> rel='alternate', and leave the rest for extensions.  -Tim

I'm about ready to admit defeat on reaching any consensus, and just go 
write an extension.  If we can't reach a consensus that includes useful 
extensibility without requiring giving up a limb or first child, let's 
just put something REALLY basic in the core so that it won't end up 
getting duplicated by extensions.  For me, it's either consensus on 
something extensible or <atom:link> with no @rel.

---

From: Sam Ruby <[email-masked]>
Date: Thu, 14 Oct 2004 15:24:29 -0400

Tim Bray wrote:
> I could go for this, only the registry should have more than one initial 
> value.  I would ruthlessly refuse any "would-be-nice" values and accept 
> only things that have been very widely deployed and used already .
> 

I'm not sure where these came from.  Who has deployed "about"? 
"attachment"?

The following values, as described in 
http://www.xml.com/lpt/a/2004/06/16/dive.html, have been deployed:

"alternate", "related", "via", and "comments".

- Sam Ruby

---

From: Tim Bray <[email-masked]>
Date: Thu, 14 Oct 2004 12:39:31 -0700

> I'm not sure where these came from.  Who has deployed "about"? 

The deployment of "about" is in some part an artifact of the fuzziness 
of the definition of <link> in RSS, and to this day I encounter feed 
items which, when I click on them, I get sent to whatever they're 
talking about.  I do claim it's a widely-deployed semantic.

Attachment was a thinko for "enclosure".  Which is going through a bit 
of a vogue right now.

> "alternate", "related", "via", and "comments".

"related" is more or less "about"?

I've never used software that actually did anything intelligent with 
"via" or "comments" links, but if people generally agree with Sam that 
they're actually in use out there, that's fine with me. -Tim

---

From: Antone Roundy <[email-masked]>
Date: Thu, 14 Oct 2004 14:00:10 -0600

> talking about.  I do claim it's a widely-deployed semantic.

Ah, good clarification, and certainly true.

> Attachment was a thinko for "enclosure".  Which is going through a bit 

I'll put in one last "I don't think this QUITE fits in <atom:link>", 
and then claim that from where the sun now stands, I will fight no more 
forever.[1]  ...but reserve the right to speak with a forked tongue.

> "related" is more or less "about"?

Similar but subtlely different.  about: "I found an article on such and 
such site, and here are my comments about it."  related: "If you want 
to read further on the topic, here are a few links you might find 
useful."

[1] Chief Joseph

---

From: Sam Ruby <[email-masked]>
Date: Thu, 14 Oct 2004 16:02:59 -0400

> "related" is more or less "about"?

I've seen a description of "related", but I haven't seen a description 
of "about".  ;-)

I agree that "related" is a widely-deployed semantic.

Despite being "in vogue", is there any meaningful sense in which other 
web resources are "attached" or "enclosed"?  I can certainly see how 
audio and mpeg versions of an entry could be the content, or the 
alternate, or simply be related.

- Sam Ruby

---

From: Tim Bray <[email-masked]>
Date: Thu, 14 Oct 2004 13:21:20 -0700

> alternate, or simply be related.

I agree that "attached" and "enclosed" aren't great names.  The real 
semantic is "here is a Web resource, typically large, which the 
publisher predicts that the user may well want to have a look at and 
we're putting the URI here outside the content to make it easy for 
clients to find."  On the face of it, the existence of this would seem 
to make podcasting relatively easier and more straightforward than 
overloading on rel="related".  Suggestions for a better name are 
welcome.  -Tim

---

From: Robert Sayre <[email-masked]>
Date: Thu, 14 Oct 2004 16:23:36 -0400

> I agree that "related" is a widely-deployed semantic.

You'll find a description of "about" in PaceLinkDelicious. When I wrote 
that, it was my underhanded way of proposing content @src.

If we have content @src, we don't need it. I think it would be totally 
cool if we renamed <content> to something like <more>, but it's not a 
big deal.

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Thu, 14 Oct 2004 13:33:05 -0700

> cool if we renamed <content> to something like <more>, but it's not a 

D'oh, of course.  Given content @src, drop attachment/enclosure/whatever

That would leave us with alternate|related for sure, and Sam claims 
that "via" and "comments" are significantly deployed, other voices pro 
or contra?

-Tim

---

From: Lucas Gonze <[email-masked]>
Date: Thu, 14 Oct 2004 16:36:28 -0400 (EDT)

On Thu, 14 Oct 2004, Tim Bray wrote:
>> Despite being "in vogue", is there any meaningful sense in which other web 
>> resources are "attached" or "enclosed"?  I can certainly see how audio and 
>> mpeg versions of an entry could be the content, or the alternate, or simply 
>> be related.
>
> I agree that "attached" and "enclosed" aren't great names.  The real semantic 
> is "here is a Web resource, typically large, which the publisher predicts 
> that the user may well want to have a look at and we're putting the URI here 
> outside the content to make it easy for clients to find."  On the face of it, 
> the existence of this would seem to make podcasting relatively easier and 
> more straightforward than overloading on rel="related".  Suggestions for a 
> better name are welcome.  -Tim

"prefetch" is an obvious candidate.  The downside is that it doesn't 
encompass all the uses supplied for the RSS 2.0 tag.

- Lucas

---

From: Robert Sayre <[email-masked]>
Date: Thu, 14 Oct 2004 16:48:11 -0400

> encompass all the uses supplied for the RSS 2.0 tag.

I'm confused. This is precisely the problem with that RSS2 tag.

"The RSS enclosure element and the Dangers of Overspecification"
http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=d9c0205d-3cc1-4efb-a62f-7b0f05fb13af

If you want to download something in the middle of the night, that's 
fine... I don't see why we should write it into the spec.

Robert Sayre

---

From: Lucas Gonze <[email-masked]>
Date: Thu, 14 Oct 2004 17:27:11 -0400 (EDT)

On Thu, 14 Oct 2004, Robert Sayre wrote:
> If you want to download something in the middle of the night, that's fine... 
> I don't see why we should write it into the spec.

I don't know yet what I think about it, because I can't figure out why the 
original enclosure tag accomplished anything at all.

- Lucas

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 14 Oct 2004 14:41:21 -0700 (PDT)

> deployed, other voices pro 

If this is the case I'd like this claim backed up with
the number of feeds and clients that support this
functionality. Also, if a feature is widely supported
by one but not the other (in lots of feeds but not
lots of aggregators) then I'd claim it isn't
"significantly deployed". 

=====

_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

---

From: Danny Ayers <[email-masked]>
Date: Fri, 15 Oct 2004 00:04:56 +0200

> (http://imc.org/atom-syntax/mail-archive/msg10481.html) which I don't

I ran Robert's suggestion across the RDF lists and got quite a bit of
response (some of which you probably  saw cross-posted, when time
permits I'll glue the core bits together and post).
Opinions varied, but were generally positive - I don't think there
were any "that's a bad idea" though naturally there were a few "here's
a better idea (called RDF)" .

I personally think having an extensible <link> could be nice sugar
(probably using URIs in @rel), but I'm fairly sure exactly the same
data could be delivered using the mechanism Robert sketched.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Danny Ayers <[email-masked]>
Date: Fri, 15 Oct 2004 00:16:33 +0200

> "significantly deployed".

I think there's a strong case for both even if there isn't significant
deployment.

Many sites feature comments feeds, they are usually in an RSS format
so will have general client support. The HTML weblog allows simple
movement between main content of an item and its comments, the
aggregator should be able to do that too.

"via" is on the one hand useful as a courtesy, on the other as a
potential means of tracking the source path of content. Both
desirable, little cost. Consider this a feature request for RSS
Bandit.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Robert Sayre <[email-masked]>
Date: Thu, 14 Oct 2004 18:30:39 -0400

>>"significantly deployed".

I reject the terms of this debate :)

If we observe overloading of an element with divergent concepts, that's 
a sign of a design flaw.

The number of people that write "via: ___" in their content is proof 
enough, IMO. We are not here to collect all the popular extensions to 
other formats under one namespace. There are a couple things that just 
need fixing.

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Fri, 15 Oct 2004 10:06:21 +1000

On 15/10/04 6:33 AM, "Tim Bray" <[email-masked]> wrote:

> Given content @src, drop attachment/enclosure/whatever

use case: I write a blog posting reviewing some latest hit. It's full of my
opinion and observations.

should this be done like this:

    <entry>
        <title>my latest hit single</title>
        <content type="text/plain">blah blha blah</content>
        <content src="latest.mp3" type="application/mpeg" />
        [... id, date, etc ...]
    </entry>

or like this:

    <entry>
        <title>my latest hit single</title>
        <content type="text/plain">blah blha blah</content>
        <link href="latest.mp3" type="application/mpeg" rel="enclosure" />
        [... id, date, etc ...]
    </entry>

e.

---

From: Eric Scheid <[email-masked]>
Date: Fri, 15 Oct 2004 10:14:12 +1000

> talking about.  I do claim it's a widely-deployed semantic.

so you mean deployed as a semantic, but not necessarily as a syntax?

> "related" is more or less "about"?

Not really. If say I wrote a blog posting about a new release movie then the
'alternate' link would point to my blog page, the 'about' link would point
to the movie site, and 'related' might point to a review on some third party
site, the previous episode in the movie series, a snarky fansite, or
whatever else is related to {my blog post+the movie site}.

(eg. if I was criticising a cops & robbers movie, I might also link to
current crime statistics as 'related')

> they're actually in use out there, that's fine with me. -Tim

I'm writing scripts to plug into NNW which will find extra links and insert
them into the <content>. I can imagine the likes of technorati doing
something interesting with 'via'.

e.

---

From: Robert Sayre <[email-masked]>
Date: Thu, 14 Oct 2004 20:29:57 -0400

> opinion and observations.

You can't have multiple content elements anymore (*stares at format 
draft), so you have to decide which is more to the point.

<entry>
	<link ... href="the.mp3">
	<content>blah blah</content>
</entry>

or maybe

<entry>
	<link ... href="review.html">
	<content src="the.mp3">
</entry>

or maybe

<entry>
	<title>the latest hit</title>
	<link rel="related" href="the.mp3">
	<link rel="related" href="review.html">
	<summary>bla bla go to the links</summary>
</entry>

The salient point being that you haven't told us anything special if you 
refuse to focus on one URI (or tree of child content).

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Thu, 14 Oct 2004 21:38:30 -0400

>         <content src="latest.mp3" type="application/mpeg" />

Was this a typo?  If the first <content/> element were a <summary/> what 
you would be doing would be syndicating a mp3, and providing an 
accessible summary.  This doesn't sound like a review.

>         <link href="latest.mp3" type="application/mpeg" rel="enclosure" />

In this case, whare you are syndicating is the text - the review itself. 
  And providing a link to something related that somebody might 
(optionally) want to download.  This sounds closer to the use case you 
described.

- Sam Ruby

---

From: Eric Scheid <[email-masked]>
Date: Fri, 15 Oct 2004 11:42:36 +1000

> accessible summary.  This doesn't sound like a review.

not a typo. I just didn't feel like typing all 1500+ words of an example
review for this email. I guess the only typo is leaving out [...] from the
first content.

> (optionally) want to download.  This sounds closer to the use case you

that's my thinking too. so content/@src is no replacement for
link/@rel='enclosure' then?

e.

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 14 Oct 2004 18:59:46 -0700 (PDT)

> link/@rel='enclosure' then?

*chuckle* 

It depends on what you think the semantics of
enclosure are. If you mean "here's some bits you can
download" then it does. Considering that's the only
semantic of RSS enclosures that exists today I'm not
sure why you think it isn't a replacement. It seems
you are trying to differentiate between when the rich
content is the content of the entry and when it is
related to the content of the entry which is a
distinction that doesn't exist in RSS enclosures. 

You are fond of claiming that all link semantics are
the same but now you seem not to think so. So which is
it? 

To put this in perspective of an aggregator, I can
imagine a user wanting to download all MP3 contents
from a feed (e.g. podcasts) but wanting the opposite
on a review site which provides a handy link to an MP3
of the reviewed song. In RSS today there is no way to
distinguish between both cases. 

=====

---

From: Eric Scheid <[email-masked]>
Date: Fri, 15 Oct 2004 13:49:27 +1000

> distinction that doesn't exist in RSS enclosures.

well silly me.

my mental model for "enclosures" has been the same as "attachments" in email
... blobs of stuff sent along *with* an actual message. The RSS2 doesn't
make any distinction either way. It certainly doesn't say something like "if
<enclosure> is present then <description> must only be a summary or be
absent". The <description> element can co-exist with the <enclosure>
element, and the <description> element can be and often is full content.

> the same but now you seem not to think so. So which is

Non-sequitor. content/@src are not <link>s. I've never made any such claim.

You are fond of claiming that there are differences while at the same time
refusing to elucidate on those differences. So just how are the semantics
for the two <link> cases here any different?

(1) review feed: entry has long review content and enclosure link to the
thing being reviewed ... if this was a review source I trust and am
interested in, then I'd want to prefetch the linked enclosure.

(2) podcasting feed: entry has just a text title, maybe a summary, and a
link to an enclosure ... again, if this was content I'm interested in I
would want to prefetch the linked enclosure.

So how are the semantics different?

This does raise an interesting question though: if an entry has both a
<summary> and a <content>, would an aggregator display both? What if they
summary was @type="text/plain" and the content was @src="some.mp3"?

> distinguish between both cases.

depends on the user and the feed. I subscribe to D. Keith Robinson's feed,
which is mostly web-development/web-standards postings, but he also posts a
Song Of The Week entry every week -- an extended review, with links, and
"Recommended if you like", and a link to the mp3. I'd want to download that.

If there was some feed dedicated to just reviews, and of which I'm simply
not interested in reading every review because they cover both kinds of
music (country AND western!), then I'd not want to waste my bandwidth
downloading every enclosure. On the other hand if I'm a music nut with too
much time and bandwidth on my hands, I might well want to download all the
enclosures on Rolling Stone's music review feed and also their movie review
feed (assuming links to preview clips). Similarly, if I just plain didn't
like DKR's taste in music then I wouldn't want to auto-fetch the songs he
reviews, despite wanting to read all his other postings.

My aggregator lets me choose how often I poll my subscriptions on a per
subscription basis. It also lets me set how much history to retain per
subscription on a per subscription basis. Setting whether I want to
auto-fetch enclosures should also be a per-subscription preference.

e.

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 14 Oct 2004 21:49:30 -0700 (PDT)

> per-subscription preference.

You're right. This should be a user controlled feature
not something dictated by the publisher of the feed. 

=====

---

From: Eric Scheid <[email-masked]>
Date: Fri, 15 Oct 2004 17:35:56 +1000

On 15/10/04 2:49 PM, "Dare Obasanjo" <[email-masked]> wrote:

> You're right. This should be a user controlled feature not something dictated
> by the publisher of the feed.
> 

although, the publisher should get some say in what links are suitable for
auto-fetching, and which are not.

robots.txt normally handles that aspect pretty well, despite the usual
problems with robots.txt in certain environments.

There is however a grey area use-case... consider how pre-fetching works
with the mozilla browser: a user requests a page, and the browser
automatically loads the images, so far all is normal, but mozilla will also
look for links on that page that are marked 'prefetch' and will start
downloading them shortly after all other inline resources have been
retrieved. Thus, if the user then clicks on the link to the next page they
can find that it is already locally cached.

I can imagine a similar usage scenario with an aggregator - it doesn't
pre-fetch linked enclosures at night, but instead waits until I click to
read (say) the long review. While I'm reading that review the enclosure is
downloading, and when I'm done it's there ready for me to listen to.

So, in a world where publishers are complaining about bandwidth drains, they
just might like the opportunity of being able to say "this particular file I
don't mind if you auto download". So while robots.txt is restrictive,
'prefetch' is permissive.

e.

---

From: Graham <[email-masked]>
Date: Fri, 15 Oct 2004 12:16:06 +0100

> link/@rel='enclosure' then?

Yes. The RSS enclosure element is a far better match for most proposed 
uses of content @src.

btw I much prefer "attachment" to "enclosure", as it's far less 
misleading.

Graham

---

From: Sam Ruby <[email-masked]>
Date: Fri, 15 Oct 2004 08:27:52 -0400

Tim Bray wrote:
> That would leave us with alternate|related for sure, and Sam claims that 
> "via" and "comments" are significantly deployed, other voices pro or 
> contra?

This is looking more and more like:

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

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Fri, 15 Oct 2004 09:33:30 -0400

Graham wrote:

> 
> btw I much prefer "attachment" to "enclosure", as it's far less misleading.

Since the resource isn't enclosed or attached, I don't understand.

Robert Sayre

---

From: Janne Jalkanen <[email-masked]>
Date: Fri, 15 Oct 2004 16:35:37 +0300

> rel='alternate', and leave the rest for extensions.  -Tim

+1 for <atom:link>.  If the list can't agree on it, it is probably too 
complex anyway - so a simple, extensible solution, that perhaps does not 
do everything, but does one thing well, might be the best choice.

/Janne

---

From: Tim Bray <[email-masked]>
Date: Fri, 15 Oct 2004 07:53:51 -0700

On Oct 15, 2004, at 5:27 AM, Sam Ruby wrote:

>> that "via" and "comments" are significantly deployed, other voices 
>> pro or contra?
>

Yes, except for we're talking about having an IANA registry to allow 
for extensibility, albeit with some difficulty. -Tim

---

From: Robert Sayre <[email-masked]>
Date: Fri, 15 Oct 2004 13:12:37 -0400

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

Off list, it has been pointed out to me that people often "blog about" 
other resources (duh!), and content @src is badly overloaded if used as 
"about". It makes sense to use content @src for flickr, or the Gillmor 
Gang. Other stuff I'm not so sure about. Then, we're getting into a 
situation where <about> is the thing you click to, but if it's not 
there, then there's alternate, or maybe content @src... so to be safe, 
put the same URI in all of em...

I'm thinking maybe we won't have a good handle on this problem until we 
deal with extensibility. This discussion seems to be proof that we are 
not getting it right.

"Get it right

If you haven't gone to the trouble of making a semantic model, then you 
may not have a well defined one."[0]

Let's also keep MarkP's wise words[1] about RDF discussions in mind. Our 
conceptual model needs some help. I am not talking about RDF syntax, RDF 
tools, or the Semantic Web.

Robert Sayre

[0] http://www.w3.org/DesignIssues/RDF-XML.html
[1] http://www.xml.com/pub/a/2003/08/20/dive.html

---------------------------------------------------

The Gillmor Gang in imaginary syntax:

<entry>
	<title>Gilmor Gang</title>
	<id>...</id>
	<updated>2004-09-24T16:45:37Z</updated>
	<alternate href="pageAboutShow.html"... />
	<link href="some-other.html" ... /><!--this is "related"-->
	<about href="gnomedex.html" ... />
	<author>
       		<name>IT Conversations</name>
       		<url>http://itconversations.com/</url>
       		<email>...</email>
     	</author>
	<summary>blah blah</summary>
	<content type="audio/mpg" src="thegang.mp3" />
</entry>

Anil Dash's linkblog in Atom 0.3:

Note that Anil has switched some stuff around on us, because Atom 0.3 
isn't quite right. How should this be written in the syntax above? Anil 
wants the "click event" to take the user to the cruftbox.com page.

<entry>
     <title>HOT SAUCE CLEANS PENNIES</title>
     <link rel="alternate" type="text/html" 
href="http://cruftbox.com/blog/archives/001034.html" />
     <link rel="related" type="text/html" 
href="http://www.dashes.com/links/archives/20040919.php#013993" />
     <issued>2004-09-24T11:45:01-05:00</issued>
     <id>...</id>
     <created>2004-09-24T16:45:01Z</created>
     <summary type="text/plain">talk about getting things done!</summary>
     <author>
       <name>anildash</name>
       <url>http://anildash.com/</url>
       <email>[email-masked]</email>
     </author>
     <content type="text/html" mode="escaped" xml:lang="en" 
xml:base="http://www.dashes.com/links/">http://cruftbox.com/blog/archives/001034.html...</content>
</entry>

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Fri, 15 Oct 2004 17:10:28 -0400

>  PaceLinkConstruct (adds rev="comment|update|replaces")

I wrote this one.  I've never said anything good about it, and I've 
usually had company when giving it the -1. Whatever we decide, it's safe 
to say that none of that Pace is going to make it in.

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Sat, 16 Oct 2004 14:42:54 -0400

Lucas Gonze wrote:
> I don't know yet what I think about it, because I can't figure out why 
> the original enclosure tag accomplished anything at all.
> 

There are some things that Dave has figured out pretty well. The main 
feature of <enclosure> is not prefetching or any such nonsense. It's the 
appearance of a paperclip icon in the user interface, just like email. 
This is subtly but critically different than content @src. So, I can see 
a use for a hypothetical <atom:paperclip> element, and I agree with 
Graham and Eric now.[0] Still think "attachment" and "enclosure" are 
terrible names, but maybe that's the best we can do.

Robert Sayre

[0] http://www.imc.org/atom-syntax/mail-archive/msg10626.html

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 18 Oct 2004 02:19:27 +0200

> Specifically: "alternate", "about", and "attachment".

Why can't we use words already known and used in Dublin Core? Or is Dublin  
Core to be considered as an extension to Atom whereas Atom _needs_ to make  
up its own named semantic in all places? I'm asking because I'm wondering.

If we were to used Dublin Core's relational names here, 'hasFormat'[1],  
'hasPart'[2], 'hasVersion'[3], 'isFormatOf'[4], 'isPartOf'[5],  
'isReferencedBy'[6], 'isReplacedBy'[7], 'isRequiredBy'[8] and  
'isVersionOf'[9] are all values we could adopt directly.

If we're not to adopt them, I think we should at least consider the way  
they're defined, because they make very much sense in a publishing  
environment.

____
[1] <url: http://dublincore.org/documents/dcmi-terms/#hasFormat>
[2] <url: http://dublincore.org/documents/dcmi-terms/#hasPart>
[3] <url: http://dublincore.org/documents/dcmi-terms/#hasVersion>
[4] <url: http://dublincore.org/documents/dcmi-terms/#isFormatOf>
[5] <url: http://dublincore.org/documents/dcmi-terms/#isPartOf>
[6] <url: http://dublincore.org/documents/dcmi-terms/#isReferencedBy>
[7] <url: http://dublincore.org/documents/dcmi-terms/#isReplacedBy>
[8] <url: http://dublincore.org/documents/dcmi-terms/#isRequiredBy>
[9] <url: http://dublincore.org/documents/dcmi-terms/#isVersionOf>

-- 
Asbjørn Ulsberg    -=|=-     http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

---

From: Martin Duerst <[email-masked]>
Date: Mon, 18 Oct 2004 15:46:38 +0900

At 12:48 04/10/14, Paul Hoffman / IMC wrote:
 >>One more thing--there's an argument for not setting the bar too high: if 
it is too difficult to get new values officially recognized, we run the 
risk of people making up new values without going through the process.  For 
this reason, it may be best to devise a mechanism that ensures (as much as 
possible) that we don't get naming collisions.  What a dilemma.
 >
 >It's one we fight with in the IETF all the time. A standards-track RFC is 
probably a reasonable bar because the extension has to come up with a clear 
description of what you are supposed to do with the link; that kind of 
description easily fits into a standards-track RFC. I think of these like 
ESMTP extensions, of which there are many.

I agree with Antone. I think a standards-track RFC is a good thing
for an ESMTP extension, because extensions to a protocol need quite
careful review. The link types are much less critical for
interoperability, and therefore a much simpler registration
should be okay. A similar move to simplify registration is also
underway for URI schemes, which are again much more central to
interoperability than link types.
One pattern that can be seen extremely often is that there is an
outside body defining a value. Sadly but truely enough, most such
bodies have difficulties understanding the fact that just specifying
a value in their own spec is not enough. The easier we make it for
them to register, the better we achieve our main goal, namely to
avoid collisions.

Regards,    Martin.

---

From: Eric Scheid <[email-masked]>
Date: Mon, 18 Oct 2004 18:08:38 +1000

> 'isVersionOf'[9] are all values we could adopt directly.

'alternate' could be either 'hasFormat' or 'isFormatOf', depending on the
chain of events and provenance that lead to the instantiation of the atom
entry. Do we need that distinction?

The (contentious) relationship denoted by 'attachment' could possibly be
represented by 'requires' (which you left off your list [10]), or by
'hasPart'. Neither are entirely satisfactory matches for the use case of a
long review with attachment.

There is no DC equivalent of 'about' that I can see.

Since we'll have to conflate a couple of distinctions, plus add in at least
one term of our own, I'm not comfortable with folding in the DC terms. It'll
cause implementation problems when people don't read the spec (instead
taking their cues from the existence of DC terms in Atom feeds), and might
be problematic for the DC camp too.

We'd likely need a core set of terms, and then allow the extensibility of
other terms (by whichever mechanism we finally decide on). Inevitably there
will be overlaps between different extension sets and even with the core.

DC has also been developed with an understanding of existing in shared
spaces, playing nicely with others. In HTML for example, they don't just
lump "isFormatOf" into the @rel of <meta>, they use "DCTERMS.isFormatOf",
sharing that attribute space with other meta-data players (such as A-Core,
AGLS, and others). I don't think they'd be mighty perturbed to do the same
here.

e.

[1]  http://dublincore.org/documents/dcmi-terms/#hasFormat
[2]  http://dublincore.org/documents/dcmi-terms/#hasPart
[3]  http://dublincore.org/documents/dcmi-terms/#hasVersion
[4]  http://dublincore.org/documents/dcmi-terms/#isFormatOf
[5]  http://dublincore.org/documents/dcmi-terms/#isPartOf
[6]  http://dublincore.org/documents/dcmi-terms/#isReferencedBy
[7]  http://dublincore.org/documents/dcmi-terms/#isReplacedBy
[8]  http://dublincore.org/documents/dcmi-terms/#isRequiredBy
[9]  http://dublincore.org/documents/dcmi-terms/#isVersionOf
[10] http://dublincore.org/documents/dcmi-terms/#requires

---

From: Walter Underwood <[email-masked]>
Date: Mon, 18 Oct 2004 10:01:03 -0700

--On Monday, October 18, 2004 02:19:27 AM +0200 Asbjørn Ulsberg <[email-masked]> wrote:

> Why can't we use words already known and used in Dublin Core?

For applications which handle blogs and other content tobether (like
search engines), using Dublin Core really helps. If we define new terms,
we will either have ad hoc mappings to Dublin Core or one more standard
to make a recommended mapping.

In the library world, a mapping between metadata schemas is called
a "metadata crosswalk". Search for that if you want to see some.
They are a lot of work.

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: Norman Walsh <[email-masked]>
Date: Wed, 20 Oct 2004 08:25:13 -0400

[ I've had my eye off this particular ball for a few weeks (to the
  tune of 750 or so messages that I've got no hope of properly catching
  up on). I guess that's a warning to assume I'm a little clueless. ]

/ Tim Bray <[email-masked]> was heard to say:
| On Oct 13, 2004, at 7:49 PM, Paul Hoffman / IMC wrote:
|
|> Would you (and others) be happy with a simple IANA registry that
|> gets filled in when there is a standards-track RFC. It would start
|> with "alternate -> RFC {ournumber}", and entries would be added as
|> the RFCs issued. FWIW, it would be perfectly permissible for a
|> single RFC to be the registration for multiple new values.
|
| I could go for this, only the registry should have more than one
| initial value.  I would ruthlessly refuse any "would-be-nice" values
| and accept only things that have been very widely deployed and used
| already .
|
| Specifically: "alternate", "about", and "attachment".
|
| And if we *can't* get consensus on this list, I say the hell with it,
| just have an <atom:link> with no @rel, used for what we now call
| rel='alternate', and leave the rest for extensions.  -Tim

That looks attractive to me. Let the community build a few extension
vocabularies, see which ones catch on, see what semantics turn out to
be useful "in the wild" and then decide what to standardize.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Where are you dying tonight?--Evelyn
http://nwalsh.com/            | Waugh