Subject: Can atom be Del.icio.us? Or, can Del.icio.us be atomic?

From: "Bob Wyman" <[email-masked]>
Date: Sat, 21 Aug 2004 11:14:00 -0400

At  <http://del.icio.us/rss/> http://del.icio.us/rss/ you'll find an
RSS/RDF feed which contains entries who purpose is to link to and
categorize pages that users have found interesting. In each RSS item,
the <link> field points to some site other than del.icio.us. There is
generally no correlation between the <description> text provided and the
content which is linked to. The entry in the feed is not an
"alternative" to the page linked to -- its function is simply to provide
a pointer, potentially with some commentary in the description and some
classification data. (A sample entry will be found below.)
    I have no relationship with the del.icio.us site, however, I'm
curious if anyone can suggest how they might convert from RSS to Atom in
the future? 
    The Atom format spec says: "atom:entry elements MUST contain at
least one atom:link element with a rel attribute value of 'alternate'."
However, there is no apparent candidate for a page that is the
"alternate" of a del.icio.us item since these items are only listed on
category pages and don't have item specific pages on the site. Given
that individual items can be listed on multiple pages (if the item has
multiple topics or keywords), even if one decided that the "alternate"
was to be the category page, they would run afoul of the requirement in
Atom that an entry can only have *one* link of type "alternate." 
    Can the del.icio.us function be provided via Atom without violating
the Atom format specification or requiring major changes to the way the
site works today?

        bob wyman

 <http://del.icio.us/rss/#> - <item
rdf:about="http://heraclitussayz.blogspot.com/">
  <title>Heraclitus sayz (the Return of the Lo-Fi)</title> 
  <link>http://heraclitussayz.blogspot.com/</link> 
  <description>Heraclitus sayz (the Return of the Lo-Fi)</description> 
  <dc:creator>omit35</dc:creator> 
  <dc:subject>blog_mp3 music</dc:subject> 
 <http://del.icio.us/rss/#> - <taxo:topics>
 <http://del.icio.us/rss/#> - <rdf:Bag>
  <rdf:li resource="http://del.icio.us/omit35/blog_mp3" /> 
  <rdf:li resource="http://del.icio.us/omit35/music" /> 
  </rdf:Bag>
  </taxo:topics>
</item>

---

From: Robert Sayre <[email-masked]>
Date: Sat, 21 Aug 2004 15:34:32 +0000

Quoting Bob Wyman <[email-masked]>:

> classification data.

Here's an example in Atom:
http://www.dashes.com/links/atom.xml

Anil is forced to relegate the actual alternate representation of his entries to
"related" in order to get the the linked page to show up in the content pane of
an  aggregator (RSS Bandit does this, I haven't tried this feed elsewhere).

This is why people want content indirection. It's already being done, in a
broken way.

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Sat, 21 Aug 2004 13:21:33 -0400

> the Atom format specification or requiring major changes to the way the

In general, multiple del.icio.us entries are related to a given web 
page.  Using a simple query, you can see a single page which contains 
all of them, for example:

http://del.icio.us/url/?url=http://www.intertwingly.net/blog/2004/07/05/Tasty

This page redirects to

http://del.icio.us/url/47febb675b419260bee19862d6479e0d

Now, if each of these entries were identified with an id, they could be 
uniquely referenced by a fragment identifier, e.g.:

http://del.icio.us/url/47febb675b419260bee19862d6479e0d#17

  - - -

Whether this constitutes a "major change", or if the requirement that an 
"atom:entry elements MUST contain at least one atom:link element with a 
rel attribute value of 'alternate'", or if we simply decide that this is 
not a valid scenario for Atom can be debated.

- Sam Ruby

---

From: Sam Ruby <[email-masked]>
Date: Sat, 21 Aug 2004 13:22:58 -0400

> an  aggregator (RSS Bandit does this, I haven't tried this feed elsewhere).

Sigh.  This is just so busted.  Dare, what can be done to fix RSSBandit? 
  Is there an additional clarification in the specification needed?

- Sam Ruby

---

From: Sam Ruby <[email-masked]>
Date: Sat, 21 Aug 2004 13:44:50 -0400

> Whether this constitutes a "major change", or if the requirement that an 

Insert "we should drop" between "if" and "the". ^^^^^^

- Sam Ruby

---

From: Dare Obasanjo <[email-masked]>
Date: Sat, 21 Aug 2004 11:00:59 -0700 (PDT)

>   Is there an additional clarification in the
 
RSS Bandit only recognizes <link rel="alternate" />
while ignoring both <link rel="related" /> and <link
rel="via /> because they are not in the Atom 0.3
spec[0,1]. 

RSS Bandit has a feature where if there is no content
or it is just a link then we fetch the web page so
there isn't blank content staring the user in the
face. Since Anil has both atom:content and
atom:summary, in his feed we pick  atom:content which
happens to only be a link so we automatically fetch
the page instead of showing the user a plain text
link. 

To disable this feature go to Options->Feed Items and
uncheck 'If no description, open link in detail
window'. Now when viewing his feed you'll see the
content which is plain text hyperlinks. 

[0] I don't plan to go back and add support for them
since I don't plan to add features based on email
threads, wiki discussions and draft specs. The next
time the Atom handling code in RSS Bandit will change
is for Atom 1.0

[1] In the meantime an RSS Bandit user can come up
with a custom XSLT stylesheet that does something
sensible with these <link> elements.

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #25
No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot.

__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

---

From: Danny Ayers <[email-masked]>
Date: Sat, 21 Aug 2004 20:11:38 +0200

----- Original Message -----
From: Bob Wyman <[email-masked]>
 
[[ 
    At http://del.icio.us/rss/ you'll find an RSS/RDF feed which
contains entries who purpose is to link to and categorize pages that
users have found interesting. In each RSS item, the <link> field
points to some site other than del.icio.us. There is generally no
correlation between the <description> text provided and the content
which is linked to.
]]

Isn't the <description> a description of the resource being described?
(It looks the same as the title in your example, which isn't far out).

[[
The entry in the feed is not an "alternative" to the page linked to --
its function is simply to provide a pointer, potentially with some
commentary in the description and some classification data. (A sample
entry will be found below.)
]]

That's reasonable within RSS 1.0 isn't it? If the entry had an in-feed
alternative to the resource, then it would be expected to appear in a
<content:encoded> element, no?

[[
    I have no relationship with the del.icio.us site, however, I'm
curious if anyone can suggest how they might convert from RSS to Atom
in the future?
    The Atom format spec says: "atom:entry elements MUST contain at
least one atom:link element with a rel attribute value of
'alternate'." However, there is no apparent candidate for a page that
is the "alternate" of a del.icio.us item since these items are only
listed on category pages and don't have item specific pages on the
site.
]]

Good question. What should be the alternate if a blog post doesn't
have a (permalinked) individual reflection somewhere on the web?

[[
Given that individual items can be listed on multiple pages (if the
item has multiple topics or keywords), even if one decided that the
"alternate" was to be the category page, they would run afoul of the
requirement in Atom that an entry can only have *one* link of type
"alternate."
    Can the del.icio.us function be provided via Atom without
violating the Atom format specification or requiring major changes to
the way the site works today?
]]

I hate to bring this up, but this is exactly the kind of case the
extensible version of <link> would have been good for. I don't think
Atom in its present form is capable of expressing the information in
the RSS 1.0 feed in a non-lossy machine-readable way.
 
Cheers,
Danny.

- <item rdf:about="http://heraclitussayz.blogspot.com/"> 

  <title>
Heraclitus sayz (the Return of the Lo-Fi)</title> 

  <link>
http://heraclitussayz.blogspot.com/</link> 

  <description>
Heraclitus sayz (the Return of the Lo-Fi)</description> 

  <dc:creator>
omit35</dc:creator> 

  <dc:subject>
blog_mp3 music</dc:subject> 

- <taxo:topics> 

- <rdf:Bag> 

  </rdf:Bag> 

  </taxo:topics> 
</item>

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 21 Aug 2004 14:12:49 -0400

Robert Sayre wrote:
> Anil is forced to relegate the actual alternate representation of his
> entries to "related" in order to get the the linked page to show up in
> the content pane of an  aggregator
	I think there is more going on here than a relegating of the
links from "alternate" to "related." What Anil is doing in his Atom feed
is making a false statement...
	I believe it is fair to say that the common understanding of
"alternate" is that it points to a page which is, in fact, an
"alternate" presentation of the same data which is in the entry itself.
Thus, the "alternate" should contain some alternative representation of
the <content> element of the entry. This is not the case in Anil's feed
since the <content> in Anil's feed is a comment *about* the page which
is said to be the alternate rather than being an actual alternate of
that page. It seems wrong that it should be necessary to make a false
statement in order to get the desired behavior.

		bob wyman

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 21 Aug 2004 19:30:00 +0100

Bob Wyman wrote:

> "alternate" 

That's the problem, right there.

cheers
Bill

---

From: Robert Sayre <[email-masked]>
Date: Sat, 21 Aug 2004 14:43:58 -0400

> statement in order to get the desired behavior.

Right. I agree completely. Anil is using the "alternate" link with the 
semantics of the RSS2 link element[0].

In NNW and Shrook (shrook shows the related link), clicking the title 
will bring you to the link specified in "alternate". This behavior *is* 
annoying for this type of blog.

Mark Pilgrim's linkblog [1] doesn't make this false statement, and 
clicking on the title then brings you to a rather boring 
diveintomark.org page with a link that you click to get to the 
article... ack.

I see Bill has responded, implying that the common understanding of 
"alternate" is wrong, but I'm not following him. I like to think of 
<content> as "what you see when you pay more attention." In this case, 
the author just wants you to visit the page in question, which is a 
little different than "alternate" in any sense, isn't it?

Robert Sayre

[0] http://blogs.law.harvard.edu/tech/rss#hrelementsOfLtitemgt
[1] http://diveintomark.org/xml/blink.xml

---

From: Sam Ruby <[email-masked]>
Date: Sat, 21 Aug 2004 15:45:13 -0400

> the RSS 1.0 feed in a non-lossy machine-readable way.

For reference, here is the complete RSS 1.0 definition of the link 
element[1]:

    The item's URL.

- Sam Ruby

[1] http://web.resource.org/rss/1.0/spec#s5.5.2

---

From: Sam Ruby <[email-masked]>
Date: Sat, 21 Aug 2004 15:46:28 -0400

> That's the problem, right there.

Can you be more specific as to what the problem as you see it is?  And I 
will ask the same question I asked to Dare: Is there an additional 
clarification in the specification needed?

- Sam Ruby

---

From: Mark Pilgrim <[email-masked]>
Date: Sat, 21 Aug 2004 16:19:59 -0400

> rel="via /> because they are not in the Atom 0.3

Thank you for once again writing code that is meticulously
spec-compliant, but useless.

-- 
Cheers,
-Mark

---

From: Dare Obasanjo <[email-masked]>
Date: Sat, 21 Aug 2004 13:22:22 -0700 (PDT)

> spec-compliant, but useless.

You're welcome. I aim to please. :)  

=====

_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 21 Aug 2004 17:30:50 -0400

> spec-compliant, but useless.
	PubSub.com also ignores "related" and "via". However, I strongly
believe that both Dare's RSS Bandit and the PubSub service are "useful"...
Certainly our users seem to agree with us...
	For there to be interoperability we need to agree on common ground.
The Atom spec should define that common ground better than RSS, with its
vast variety of flavors, has done. We look to Atom to provide a more
rigorous specification that will make interop easier. 
	While we're waiting for Atom to be finalized, I think we should all
avoid making or recognizing informal extensions to Atom as documented. By
doing so, we will get a much better idea of what is missing from the core
set of Atom features and we can avoid some potential for future interop
issues when things that might be implemented as private extensions today
become differently defined standardized elements tomorrow.
	Our goal should be to write a specification that allows (in Mark's
words [1]) "assholes", "morons" and "angels" to all interoperate correctly
and comfortably. 
	The example that I presented at the beginning of this thread
concerning del.icio.us, is instructive. Anil Dash has "solved" the
del.icio.us problem by 1) Violating the common understanding of the meaning
of "alternate" and by 2) Introducing the non-standard "rel='related'" to do
what most would have expected "alternate" to do.
	Certainly, there are all sorts of creative solutions to problems
that can be achieved using Dash's methods or other hacks. However, such
hacks tend to harm interop in the long run even if they appear, by hiding an
issue, to solve problems in the near term.

		bob wyman

[1] http://diveintomark.org/archives/2004/08/16/specs

---

From: Danny Ayers <[email-masked]>
Date: Mon, 23 Aug 2004 12:55:12 +0200

> For reference, here is the complete RSS 1.0 definition of the link

Below is the example of the del.icio.us feed. You may note it contains
considerably more than a simple <rss:link> element.  That the rss:link
element doesn't do much is irrelevant. The proposed extensible form of
atom:link would have allowed something like:

<entry ...>
...
<link rel="tx:topic" href="http://del.icio.us/omit35/blog_mp3" />
<link rel="tx:topic" href="http://del.icio.us/omit35/music" />
...
</entry>

Cheers,
Danny.

---

From: Robert Sayre <[email-masked]>
Date: Mon, 23 Aug 2004 12:37:25 -0400

> issue, to solve problems in the near term.

Just to be perfectly clear, I consider this a failure of the spec to 
provide a feature that RSS has. The RSS2 link element is vague/versatile 
enough to allow the behavior that Dash was after.

What are some possible approaches for this feature? I can imagine an 
<about> link.

Also, does anyone feel that this feature is out of scope?

Robert Sayre

---

From: Graham Parks <[email-masked]>
Date: Mon, 23 Aug 2004 13:42:03 -0400

>What are some possible approaches for this feature? I can imagine an 

Mark Pilgrim's excellent proposal is here:
http://www.xml.com/lpt/a/2004/06/16/dive.html

Someone write a Pace. Shrook already supports related and via links*.

Graham

(* NB my objection to the <link> tag syntax itself still stands, backed up by the convoluted code required to implement this feature)

---

From: Robert Sayre <[email-masked]>
Date: Mon, 23 Aug 2004 13:56:41 -0400

> Someone write a Pace. Shrook already supports related and via links*.

OK, there are old threads[0] about this. Some people (including myself) 
wanted a 'primary related'/'about' relation, so there would be a default 
link, if desired.

How does that sit with aggregator authors? Seems like it would make life 
easier. Mark's sequence of 'related' links leans on ordering a little 
too much, doesn't you think?

Robert Sayre

> (* NB my objection to the <link> tag syntax itself still stands, backed up by the convoluted code required to implement this feature)

oi... let's not go there right now.

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

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 23 Aug 2004 14:31:23 -0400

> Someone write a Pace. Shrook already supports related and via links*.
	Even if everyone implemented what Mark has proposed, you still
wouldn't necessarily get the behavior that Anil Dash achieves by switching
his "alternate" and "related" links. What is missing from Mark's proposal is
some indication of the relative significance or primacy of links. In the
LinkBlog case, the entry is mere annotation and even if it has an alternate,
that alternate is NOT the "interesting" bit. The interesting bit is the
related link. However, in "normal" blogs, the "alternate" is the interesting
bit and the related stuff is just that -- related... To get the behavior
apparently sought by Anil, one would need to give the aggregator some sort
of hint that said that the related link should be considered "primary" even
though it wasn't the alternate.
	See the stuff below, copied from Anil's atom feed and modified to
make the alternates and related links correct while adding a "primary='yes'"
attribute to the related link. (Yes, I know its ugly. Read it for semantics
-- not syntax.)

- <entry>
  <title>David Carlson's Online Timeline</title> 
  <link rel="alternate" 
     type="text/html"
     href="http://www.dashes.com/links/archives/20040822.php#013842" />
   <link rel="related" 
     primary="yes"
     type="text/html" 
     href="http://iml.jou.ufl.edu/carlson/timeline.shtml" /> 
  <modified>2004-08-23T18:16:19Z</modified> 
  <issued>2004-08-23T13:15:50-05:00</issued> 
  <id>tag:www.dashes.com,2004:/links//5.13842</id> 
  <created>2004-08-23T18:15:50Z</created> 
  <summary type="text/plain">a fascinating history of online systems,
complete with screenshots</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://iml.jou.ufl.edu/carlson/timel
ine.shtml...</content> 
  </entry>

	Of course, an alternative would be to do what NewsML does and that
is to allow the "content" of an item to be specified by an URL rather than
included in the entry. Also, like NewsML, provide for both a summary and the
primary content itself. In NewsML, you might do something like:

<NewsItem>
  <NewsComponent>
    <Role FormalName="Summary"/>
    <ContentItem>
      <DataContent>
This is the summary... It talks about some other page.
      </DataContent>
    </ContentItem>
  </NewsComponent>
  <NewsComponent>
    <Role FormalName="Main"/>
    <ContentItem Href=" http://iml.jou.ufl.edu/carlson/timeline.shtml "/>
  </NewsComponent>
</NewsItem>

Note: Readers could be "taught" to display the summary in lists, but to open
the "Main" entry when clicked on... I think this would do what Anil and
others want.

		bob wyman

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 23 Aug 2004 14:40:40 -0400

- <entry>

<NewsItem>
  <NewsComponent>

		bob wyman

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 23 Aug 2004 11:56:45 -0700 (PDT)

> the "Main" entry when clicked on... I think this

Aggregators already do this today. If Anil's feed
didn't have the bogus <atom:content> element then the
behavior you'd see in RSS Bandit is exactly what you
describe. 

=====

---

From: Robert Sayre <[email-masked]>
Date: Mon, 23 Aug 2004 15:17:42 -0400

> behavior you'd see in RSS Bandit is exactly what you

Let's look at Anil's feed again. If the following entry didn't have a 
bogus <content> element, which link would RSS Bandit use as the "main" 
link, and which link is the actual alternate represention of the entry? 
Do you agree that this is broken?

Robert Sayre

<entry>
<title>technorati gets funded</title>
<link rel="alternate" type="text/html" 
href="http://www.gigaom.com/2004/08/technorati_gets.php"/>
<link rel="related" type="text/html" 
href="http://www.dashes.com/links/archives/20040822.php#013844"/>
<modified>2004-08-23T18:48:33Z</modified>
<issued>2004-08-23T13:48:33-05:00</issued>
<id>tag:www.dashes.com,2004:/links//5.13844</id>
<created>2004-08-23T18:48:33Z</created>
<summary type="text/plain">
appropriate that om got this scoop on a blog instead of a print mag
</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://www.gigaom.com/2004/08/technorati_gets.php...
</content>
</entry>

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 23 Aug 2004 12:34:23 -0700 (PDT)

> Do you agree that this is broken?

Nope. As a user of an aggregator reading a link blog I
think the behavor is what I'd expect. Why would I want
the main link my aggregator displayed be a link to
Anil's blog instead of the link to the main item? Then
it takes me two clicks to visit the linked item
instead of one. 

=====

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

---

From: Robert Sayre <[email-masked]>
Date: Mon, 23 Aug 2004 15:40:21 -0400

> it takes me two clicks to visit the linked item

OK, we agree with each other (I think...). I meant to ask if you think 
the format spec is broken. That link is not the alternate representation 
of the entry, but it is certainly the one that I want to click on. 
Wouldn't it be better if Anil could write

<link rel="about" uri="some other site" />
<link rel="alternate" uri="http://dashes.com/..." />

Robert Sayre

---

From: Danny Ayers <[email-masked]>
Date: Tue, 24 Aug 2004 00:15:18 +0200

> provide a feature that RSS has. 

Agreed.

The RSS2 link element is vague/versatile
> enough to allow the behavior that Dash was after.

I would suggest that versatile doesn't have to be vague and that
actually supporting the behaviour is a different matter entirely.
There are plenty of weaknesses in RSS 1.0, but it can express
information like this unambiguously. Whether applications support the
desired behaviour is another matter. Down the path of vagueness lies
beauty such as HTML escaping in RSS2 descriptions.

What puzzles me is how everyone seems to be of the opinion that
quick-and-dirty hacks are unlikely to be useful long term, yet still
prepared to build on the most fragile parts of existing systems.

I would suggest that in this particular case a useful long term
solution won't be found by hacking the feed to create behaviour to
match the publisher's intent, but - well, errm - trying to get both
ends to use a common format specification. In cases like this I would
suggest that the feed itself should be entirely declarative with the
data and leave it up to the consumer software/end user to determine
the behaviour of the application.

It's all very well basing a specification on established
implementation, but building around particular bits of hackiness in
particular tools is just likely to make things fragile.

> What are some possible approaches for this feature? I can imagine an

Yes, that could well be useful. But there we're running into the
conflict between an easily-managed small number of well-defined terms
and the large number needed to support a wide range of scenarios.
Either a choice has to be made between those two alternatives, or the
nettle of extensibility has to be grasped.

Atom may be coming along in places, but still a lot of it seems
destined to inherit many of the worst features of each of its
predecessors, and few of the good ones.

Cheers,
Danny.

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 23 Aug 2004 15:38:07 -0700 (PDT)

> nettle of extensibility has to be grasped.

When all the issues with the so-called "extensibility"
provided by link elements was being discussed I didn't
see you propose any solutions. Do you have any now? 

=====

---

From: Graham Parks <[email-masked]>
Date: Mon, 23 Aug 2004 21:44:08 -0400

>though it wasn't the alternate.

That's exactly the issue - that knowing the kind of link doesn't tell the aggregator where the user probably wants to go next. But I think you miss that in both cases the user knows where to go to next - they know if they're reading a link blog to look (in Shrook) in the related links box. The problem is that aggregators (including Shrook) that guessed that the user always wants to go to RSS's <link> don't know that. There' an easy solution though. In Shrook there's currently a switch that toggles between showing the entry and the "alternate" link. There's no reason why it couldn't cycle through those two and the "related" links, or pop up a menu. It's a bit of extra hassle for the user, but it's only because of richer functionality.

Graham

---

From: Danny Ayers <[email-masked]>
Date: Tue, 24 Aug 2004 11:34:08 +0200

> see you propose any solutions.

Well I did, see:

PaceLinkRelMechanism on the Wiki and

http://dannyayers.com/2003/12/link.html

> Do you have any now?

QNames in attributes aren't something I'm a fan of, but as XHTML 2.0
appears set to include them then a variation of the technique above
using them would seem a good pragmatic solution.

Cheers,
Danny.

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 24 Aug 2004 10:00:58 -0700 (PDT)

> using them would seem a good pragmatic solution.

I guess you missed the discussion on the list that
pointed out that this isn't any more of an
extensibility mechanism than just using namespaced
elements since there is no uniform way to deal with
<link> elements? 

=====

---

From: Danny Ayers <[email-masked]>
Date: Tue, 24 Aug 2004 19:46:41 +0200

> elements since there is no uniform way to deal with

I did catch most of a related discussion, but haven't see anything to
support what you're suggesting. The whole idea of defining <link>
elements in this way is to help deal with certain kinds of data
uniformly. Using <link> to denote an explicit relationship between the
parent element/entity and another URI is a considerably narrower
constraint than arbitrary (namespaced) elements and attributes that
may appear anywhere with arbitrary semantics. By adding constraints,
the chances of interoperability are increased.

Cheers,
Danny.

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 24 Aug 2004 11:09:42 -0700 (PDT)

> the chances of interoperability are increased. 

1.) The various link elements proposed in Atom have
arbitrary semantics. 

2.) For links to provide a way to 'deal with certain
kinds of certain kinds of data uniformly' you need to
define these classes of data and how they should be
treated. The last time this came up people balked at
creating what was effectively a type system for links.

=====

__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail

---

From: Danny Ayers <[email-masked]>
Date: Wed, 25 Aug 2004 01:18:32 +0200

> 1.) The various link elements proposed in Atom have

Not entirely, there are quite a number of constraints. They express a
binary relationship between two unambiguously defined entities. The
relationship is directional and defined by the value of the rel
attribute. This, on top of the disambiguation of namespace
qualification offers a mechanism which is versatile without being
vague.

> creating what was effectively a type system for links.

I wouldn't personally have described it as a type system for the
links, more for the parent & child entities involved, building on the
typing of elements in the core spec. But whatever you prefer to call
it it's potentially useful. If people want to balk that's entirely up
to them.

I don't myself think the link mechanism is perfect, not even adequate.
But at the moment the other alternatives are either limiting the
applicability of Atom (by restricting things to core terms) or
allowing anything anywhere (with namespaces) and introducing a barrier
to interop.

Cheers,
Danny.

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 24 Aug 2004 17:11:22 -0700 (PDT)

> qualification offers a mechanism which is versatile

To consumers of Atom feeds they have arbitrary
semantics. It seems you are confusing uniform syntax
with uniform semantics. According to the current draft
specs a link could mean (1) users can click here to
see human readable content related to the entry (2)
the URI to send HTTP requests using a variety of
methods [DELETE, POST, PUT, GET] to interact with the
entry (3) a link to an Atom feed that contains entries
that are related to this one in some linear sequence. 

These are pretty arbitrary semantics only connected by
the fact they share uniform syntax. Considering all
the various proposals for potential link elements that
have shown up it is even more clear that if such an
"extensibility" mechanism was chosen there would be
little connection between the semantics or aggregator
behavior on consuming these links besides uniform
syntax. 

> allowing anything anywhere (with namespaces) and

You're kidding right? How is seeing an entry with 

 <link href="ftp://www.example.com/pool.js"
type="text/javascript" rel="make-it-crunk" />

any different from seeing the same one with 

 <cc:crunchitize-me-capn
http:cc="http://www.example.com/cc">
 
<cc:file-location>ftp://www.example.com/pool.js</cc:file-location>
 </cc:crunchitize-me-capn>

What exactly makes the former a recipe for
interoperability and the latter a barrier? Do you
seriously think that the fact that one could render
the latter in the browser as a clickable link somehow
makes it more useful than the latter? If so do you
think the same about rel="service.post" and rel="service.edit"?

=====

---

From: Danny Ayers <[email-masked]>
Date: Wed, 25 Aug 2004 11:16:07 +0200

[cc list trimmed]

> behavior on consuming these links besides uniform

The way <link> has been proposed, syntax is uniform and the semantics
are uniform and restricted, not arbitrary:

<xxx>
<link rel="yyy" href="zzz" title="aaa" />
</xxx>

can be defined to express a directed relationship yyy between entities
xxx and zzz (the subject xxx will most commonly be an entity defined
in the Atom spec). yyy and zzz will be URIs (or be resolvable to
URIs), unambiguously identifying the relationship and object. The
title, aaa can provide a label for the relationship.

In terms of implementation, an aggregator could have a set of specific
behaviours will be associated with values for yyy (perhaps also
dependent on the parent element). Presumably Atom consumers will
already have such a mapping for the core values of 'rel'. In other
words a bunch of methods selectable by yyy which take a URI (zzz) as
their argument.

> interoperability and the latter a barrier? 

The former can offer uniform syntax and well-defined semantics, based
on the simple definition above. I don't know of any systematic way of
interpreting the latter example. The syntax and semantic restrictions
mean that it should be possible to avoid/minimise collisions between
extensions relatively easily. With namespaces alone that is a hard
problem.

In terms of implementation, the same class/method selector code could
be used for all <link> elements. Parsing can take place at the level
of the rest of the Atom syntax. On the other hand, every new piece of
syntax like crunchitize-me-capn will need 1. new code for parsing (on
top of Atom) and 2. new code for routing of the discovered arguments
to the appropriate handlers. You would probably need some conflict
resolution code too, for cases where extension material from different
namespaces was linked to incompatible sets of behaviour.

Additionally every producer would need a corresponding block of syntax
construction code for each crunchitize-me-capn extension. The <link>
construction code simply needs code to place it in the appropriate
part of the tree (which is probably already available from core
handling) and two or three setter methods: href, rel, title.

Do you
> think the same about rel="service.post" and rel="service.edit"?

I'm not sure what you mean. The <link> example could easily be
rendered as a clickable link if that was an appropriate rendering,
though given the values for 'rel' that have been suggested I would
think that would be the exception rather than the rule.

Cheers,
Danny.

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 25 Aug 2004 07:43:47 -0700 (PDT)

> title, aaa can provide a label for the relationship.

I give up. Telling me that I get a {rel, uri} pair and
that gives me some semantics is a joke. If I didn't
know you were one of the RDF-will-save-the-world
clique I'd have assumed you were trolling since no one
can be this obtuse without being deliberate. 

> words a bunch of methods selectable by yyy which

Can you show me this code? Even better why don't you
send me the patch for RSS Bandit that can handle any
arbitrary {uri, rel} pair and correctly interprets
their semantics without doing something stupid like
displaying the rel="service.post" URI as a clickable
link. 

I guess this is where RDF and OWL show up to save the
day. 

=====

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 25 Aug 2004 16:15:02 +0100

Hi,

I'd like to draw the chair's attention to these sprited rejoinders. 
since they're not helping us make progress wrt the Del.icio.us 
issue. Utterances from the chairs about staying focused and 
maintaining a basic level of civility would be much appreciated.

On a personal note. If I see another  ill-mannered, ill-informed, 
ill-engaged, ill-defined spat about "extensibility" or "versioning" 
viz RDF/XML/URIs, I'll surely scream, or start killfiling. As 
someone who uses both RDF and XML to get things done, I'm getting 
really annoyed about this.

cheers
Bill

---

From: Danny Ayers <[email-masked]>
Date: Wed, 25 Aug 2004 17:43:16 +0200

> I'd like to draw the chair's attention to these sprited rejoinders.

No need Bill, I've had enough. The extensibility thread (dating back
since before Atom got its name) might as well have been killfiled
already.

Cheers,
Danny.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 25 Aug 2004 08:50:25 -0700

At 4:15 PM +0100 8/25/04, Bill de hÓra wrote:
>Utterances from the chairs about staying focused and maintaining a 
>basic level of civility would be much appreciated.

So uttered. It is always better to use technical arguments than 
personal attacks. If you can't think of anything to say that has 
technical merit, silence should be considered a strong option.

>really annoyed about this.

It would be a very major shift for this WG to change the Atom format 
to RDF. If someone wants to make a proposal for that, they should 
have a list of at least three active WG members as co-proponents 
before starting the discussion. Further, they should expect a fair 
amount of criticism for re-hashing old arguments. Absent an active 
proposal, discussing advantages of RDF or other significant base 
changes is out of scope.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 25 Aug 2004 08:55:22 -0700 (PDT)

--- Bill_de_hÓra <[email-masked]> wrote:

> issue. 

How are they not? If there was <link> extensibility
and link types defined then Del.icio.us and Mark
Pilgrim can cook up all the link types they want as
long as there was some consistent way to know how to
treat link types. 

Heck, a straightforward solution would be just to use
XLink or define some profile of XLink to use in Atom.
The only problem seems to be that no one wants to step
up to the plate and do it. I'm not interested enough
in the problem to spend time on it but that seems like
a decent solution. 

=====

---

From: Sam Ruby <[email-masked]>
Date: Wed, 25 Aug 2004 12:23:33 -0400

> long as there was some consistent way to know how to

Statements like "If I didn't know you were one of the 
RDF-will-save-the-world clique I'd have assumed you were trolling since 
no one can be this obtuse without being deliberate."[1] do not further 
the goals of having a productive technical discussion.  Reminder: 
"Sometimes it is easy to forget that the people on the other end of an 
email thread aren't former denizens of git.talk.flame who relish 
technical arguments spiced with flame."[2]

> in the problem to spend time on it but that seems like

At the moment, the Atom link element is modelled after the HTML link 
tag[3], which has a number of advantages[4].

- Sam Ruby

[1]<http://www.imc.org/atom-syntax/mail-archive/msg08843.html>
[2]<http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=0fc88c00-5347-4f73-912b-15016a861af4>
[3]<http://www.w3.org/TR/REC-html40/struct/links.html#h-12.3>
[4]<http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=d9c0205d-3cc1-4efb-a62f-7b0f05fb13af>

---

From: Henry Story <[email-masked]>
Date: Wed, 25 Aug 2004 18:23:59 +0200

On 25 Aug 2004, at 17:50, Paul Hoffman / IMC wrote:
> to RDF. If someone wants to make a proposal for that, they should have 
> a list of at least three active WG members as co-proponents before 
> starting the discussion. Further, they should expect a fair amount of 
> criticism for re-hashing old arguments. Absent an active proposal, 
> discussing advantages of RDF or other significant base changes is out 
> of scope.

I don't think that Danny was proposing to shift to RDF. He was in fact 
putting forward an extremely minimalist proposal for allowing 
extensibility in Atom, following furthermore a convention to be adopted 
by the next version of xhtml. Without a proposal of the sort it would 
seem there is no way that Atom can fulfill one of the elements of the 
charter [1], namely:

-----8<---------------------------------------------
The working group will also take steps to ensure interoperability, by:
	• 	unambiguously identifying required elements in formats
	• 	clearly nominating conformance levels for different types of 
software
	• 	providing clear extensibility mechanisms and constraints upon them
-----8<---------------------------------------------

So given that the above is an avowed goal of this group, it is clear 
that
Dare Obasanjo's comment:

>  If I didn't

is in fact extreemly impolite given the huge effort and calm shown by 
Danny Ayers in explaining this issue.

I myself think that this RDF issue should be re-opened, because I have 
not yet seen any good arguments against it and it is fully supported by 
the founder of the web himself, Tim Berner's Lee. If that is not a good 
enough pedigree for an idea I don't know what is.

If Dare Obansanjo has to rewrite a few scripts if we find we have to 
change things, then I can just say I am very sorry for him. But this is 
a forum for creating a powerful, top notch, earth chattering protocol, 
or else everyone here is just wasting everyone else's time.

> --Internet Mail Consortium

[1] http://xml.coverpages.org/IETF-atompubProposed.html

---

From: Danny Ayers <[email-masked]>
Date: Wed, 25 Aug 2004 18:34:44 +0200

> proposal, discussing advantages of RDF or other significant base

I fully accept that the Atom format isn't going to be RDF/XML, and
that there won't be a normative RDF model for Atom.

But if you look back to the start of the del.icio.us thread the issue
raised was that Atom couldn't do something that RSS/RDF could. In or
out of of scope?

For the record, my suggestion for handling this case did not involve RDF.

Cheers,
Danny.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 25 Aug 2004 09:53:36 -0700

>raised was that Atom couldn't do something that RSS/RDF could. In or

In scope. Some of the recent discussion has the strong scent of 
"re-hash", but it hasn't been beaten to death yet. Specific 
proposals, done as paces, might be appropriate right about now...

--Paul Hoffman, Director

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 25 Aug 2004 09:48:00 -0700

At 6:23 PM +0200 8/25/04, Henry Story wrote:
>I myself think that this RDF issue should be re-opened, because I 
>have not yet seen any good arguments against it and it is fully 
>supported by the founder of the web himself, Tim Berner's Lee. If 
>that is not a good enough pedigree for an idea I don't know what is.

Pedigree is worth something, but not so much, in the IETF. Even Vint 
Cerf has made some proposals that have not been adopted.

You need:

- A clear and precise proposal

- A handful of backers who have been active so far this WG

- An expectation of backlash

If have those things, bring them as a package to the mailing list.

>change things, then I can just say I am very sorry for him. But this 
>is a forum for creating a powerful, top notch, earth chattering 
>protocol, or else everyone here is just wasting everyone else's time.

Fully disagree. We don't need to shatter anything in order to succeed 
well. We to come up with a set of protocols that are clear, clean, 
extensible, and will stand up well to a decade or more of 
unpredictable change around them.

There are many ways to get there. Being unwilling to change one's 
mind, feeling superior to others, and making personal attacks is one 
way. My experience in the IETF leads me to think that there are 
better ways that, when used, lead to better protocols because more 
people have actively participated and fewer people have been driven 
away.

--Paul Hoffman, Director

---

From: Dan Brickley <[email-masked]>
Date: Wed, 25 Aug 2004 13:05:23 -0400

* Danny Ayers <[email-masked]> [2004-08-25 18:34+0200]
> that there won't be a normative RDF model for Atom.

Likewise I'm not expecting Atom to use RDF/XML for its syntax.

Re 'normative RDF model', I didn't realise the model / extensibility 
issue was closed yet, and Sam's reply to my message last week 
left me thinking that RDF's datamodel (though not the XML notation) 
might still prove useful to Atom. Whether that happens depends 
on the extent of Atom's ambitions regarding extensibility beyond the 
blog-centric core. BTW I apologise for starting that big thread 
last week then dropping off the planet (actually I was in the N
etherlands, but in meetings and offline). I'm trying to catch up on 
that thread this week, will try not to rehash old debates. Regarding
concrete proposals, I proposed that the http://nature.com/rss/ Jobs use
case be taken on board by this WG as 'something we could try to make
sure was do-able in Atom'. I guess I should go read up on the proper
process for articulating that request.

BTW I hope my contributions last week made clear that I'm not in the (empty
AFAIK) 'RDF will solve all problems' camp. It's just the only way I know
of to do decentralised, loosly coordinated and fine-grained namespace mixing. 
I'm very open to their being other ways to do this in XML, I just haven't
encountered any yet.

Dan

---

From: Tim Bray <[email-masked]>
Date: Wed, 25 Aug 2004 10:07:21 -0700

On Aug 25, 2004, at 9:23 AM, Henry Story wrote:

> putting forward an extremely minimalist proposal

Sorry, I was having trouble keeping up with that thread.  Is there a 
Pace from Danny or someone capturing the proposal?  The delic.io.us 
use-case is potentially instructive.

> I myself think that this RDF issue should be re-opened

So re-open it.  Write a Pace, see if you can build consensus around it. 
-Tim

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 25 Aug 2004 10:21:43 -0700 (PDT)

> tag[3], which has a number of advantages[4].

Yes, if all the links have similar semantics.
Specifically what comes to mind is if as a fallback
they can all be rendered as human clickable links. In
fact, that simple guideline is probably all that is
really needed in the Atom case. Although it will mean
that for consistency that Atom shouldn't use atom:link
for the various service URIs which doesn't seem like a
bad tradeoff to me. 

=====

---

From: "Roger B." <[email-masked]>
Date: Wed, 25 Aug 2004 12:32:32 -0500

> But this is
> a forum for creating a powerful, top notch, earth chattering protocol...

Henry: Atom is an alternative to RSS and the Blogger/Metaweblog API... I
dunno about you, but that doesn't quite meet my standard for earth
shattering. Nor was the destruction of worlds on most folks' Atom
implementation agenda, last I looked.

Except maybe Dare. What with all of his evil overlord plans and all.

--
Roger Benningfield

---

From: Danny Ayers <[email-masked]>
Date: Wed, 25 Aug 2004 19:32:04 +0200

> issue was closed yet, 

Sorry, it probably isn't - I read too much into Paul's post.

> and Sam's reply to my message last week
> might still prove useful to Atom. 

You're not alone. I know I'm not the only one who wanted RDF
through-and-through, but also I believe several of the folks who were
adamantly against RDF/XML syntax are actually pro-model. (See Mark
P's. article of a year ago (!) : "So is the RDF model a good thing? I
think that it is; considering it made our format better, regardless of
the syntax." [1]).

Whether that happens depends
> process for articulating that request.

If doing the kind of things RSS 1.0 could do actually is in scope,
then I'd add as a use case the growing number of RSS 1.0 feeds (such
as [2], [3]) that identifier authors/contributors using FOAF. Whatever
that is ;-)
 
Cheers,
Danny.

[1] http://www.xml.com/pub/a/2003/08/20/dive.html
[2] http://feeds.feedburner.com/BenHammersleysDangerousPrecedent
[3] http://www.wasab.dk/morten/blog/feed/rdf

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 25 Aug 2004 10:34:58 -0700 (PDT)

--- Dan Brickley <[email-masked]> wrote:
> Regarding

I don't see a use case articulated at the end of that
link just links to a bunch of RSS 1.0 feeds with some
extension elements from the Nature Jobs namespace. 

To articulate a use case I'd expect to hear what
information the producer would like put in the feed
and what is expected for consumers to do with that
information. 

> I'm very open to their being other ways to do this

Sounds like a contradiction. How can you claim to be
open minded if you've already decided that 'RDF is the
only way'? 

Also I'm not sure what is meant here by namespace
mixing. Mixing the syntax of two XML vocabularies can
be done with strcat() in C. However I'm sure that's
not what you mean. So what do you mean? 

=====

		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

---

From: Danny Ayers <[email-masked]>
Date: Wed, 25 Aug 2004 19:54:55 +0200

On Wed, 25 Aug 2004 10:07:21 -0700, Tim Bray <[email-masked]> wrote:
> Pace from Danny or someone capturing the proposal?  

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

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 25 Aug 2004 11:20:36 -0700 (PDT)

--- Danny Ayers <[email-masked]> wrote:
 
Besides defining a syntax for link elements I'm not
sure what else is in this Pace. Below are some
questions about aspects of the Pace 

[If namespaces are used as described, the link element
can be mapped onto RDF properties, providing a huge
gain in interoperability and existing properties (such
as foaf:depiction in the example below) could
immediately be used within Atom. ]

Can you explain how these gains in interoperability
manifest themselves. For example, how does Bloglines
or RSS Bandit reap these supposed gains in
interoperability in comparison to just sticking a
<foaf:depiction> element in the feed? 

[Note that the 'href' name might be less than ideal -
most of the time this won't be a clickable link. ]

So this means that I can't even fallback on the
default behavior of rendering every atom:link not
understood as a clickable link in the UI? 

OK, I guess I now see where this proposal is going.
It's tailored towards the RDF scenario. Most
aggregators will ignore unknown links the same way
they do unknown elements but SemWeb aware applications
could use RDF/OWL/etc to somehow learn what to do with
such data. 

I dislike this Pace because it violates the principle
of least surprise. Basically atom:link elements would
in many cases not actually be human clickable links
which to many would be unexpected.  

=====

---

From: Robert Sayre <[email-masked]>
Date: Wed, 25 Aug 2004 14:14:24 -0400

> Someone write a Pace. Shrook already supports related and via links*.

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

Rationale
----------------
The current Atom Link values are not expressive enough for current use 
cases.

See: Can atom be Del.icio.us?[0]
      There is No FAQ [1]

Proposal
----------------
Keep a link with @rel value "alternate" mandatory, but allow a single 
link @rel value of "about" to also be present. Add an additional @rel 
value of "related" to allow links to additional resources.

This proposal is not advocating a particular syntax or extensibility 
approach for Link Constructs. It uses the method specified in the 
current draft.

The small changes to the spec can be found on the wiki page.

Robert Sayre

[0] http://www.imc.org/atom-syntax/mail-archive/msg08730.html
[1] http://www.intertwingly.net/blog/1494.html

---

From: Tim Bray <[email-masked]>
Date: Wed, 25 Aug 2004 11:31:09 -0700

> questions about aspects of the Pace

It seems like a straightforward trade-off... do you have a small set of 
link types that are wired right into the Atom vocabulary, or do you 
consciously put an extensibility point around link types?  If you want 
the latter, the mechanism here is OK (except for qnames in attribute 
values, which are a horrible, broken idea even if the HTML working 
group wants to use them).  I think the delic.io.us use-case throws a 
nice useful highlight on this one; does this type of link deserve its 
own special built-in markup ("about" rather than "alternative"), or is 
it evidence of the fact that there are an unbounded number of 
interesting link types, so we should go for extensibility?  My personal 
leaning would be for the former, but I can certainly see both sides of 
the argument. -Tim

---

From: Sam Ruby <[email-masked]>
Date: Wed, 25 Aug 2004 14:21:51 -0400

> for the various service URIs which doesn't seem like a

Let's see if I can capture that and see if there is a basis that we can 
build upon.  With a mental model of something html link-ish (leaving 
open the possibility to a number of tweaks), which of the following can 
we agree upon?

(1) Each atom:entry element must have one or more link elements 
associated with it.

(2) Exactly one of those link elements is to be considered the 'primary' 
or 'default' link.

(3) href attributes specify the location of a Web resource, thus 
defining a link between the current entry (the source anchor) and the 
destination anchor defined by this attribute.

(4) For those hrefs which are http, consumers can assume that http GET 
is supported for that uri.  Such GET requests are likely to return 
results with the mime type indicated by the type attribute.

Now, looking at Mark's http://www.xml.com/lpt/a/2004/06/16/dive.html,

(5) Exactly one of those link elements is to be considered a 'permalink'.

(6) Linking to related articles is a valid use case for this element.

(7) Linking to sources is a valid use case for this element

(8) Linking to comment feeds is a valid use case for this element

(9) Linking to next/previous archives is a valid use case for this element

(10) Linking to service interfaces is a valid use case for this element

Notes:

  a) I intentionally split out (2) and (5) based on the prior discussion
     about the virtues of being vague/versatile.

  b) It is not clear to me that (4) and (10) are mutually exclusive.

  c) Extensibility is a separate discussion.

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Wed, 25 Aug 2004 14:43:31 -0400

>  b) It is not clear to me that (4) and (10) are mutually exclusive.

I think @href is a misnomer for service interfaces. They aren't 
hypertext. They are "logical information ... not intended to be browsed 
by people as a document." [0]

Robert Sayre

[0] http://www.w3.org/DesignIssues/XLink.html

---

From: Danny Ayers <[email-masked]>
Date: Wed, 25 Aug 2004 20:53:30 +0200

On Wed, 25 Aug 2004 11:20:36 -0700 (PDT), Dare Obasanjo <[email-masked]> wrote:
> sure what else is in this Pace. 

It defines a mechanism for their interpretation.

> Below are some

The most immediate gains are disambiguation and code reuse. 
If you stick a <foaf:depiction> in the feed, say underneath an <entry>
how should it be interpreted? Using <link> you would know that this
related to the parent <entry> rather than any other elements (such as
the <feed>). The same dispatching code (to trigger behaviour) can be
used for all extensions of this structure. The data structure doesn't
in itself provide the semantics, it just makes it easier to define and
interpret.

> understood as a clickable link in the UI?

Given the broad range of interpretation/behaviour already suggested
for <link>, that would probably be a bad idea.

> could use RDF/OWL/etc to somehow learn what to do with

I wouldn't say it was tailored towards the RDF scenario, although it
does share the idea of a binary relation between web resources. Forget
RDF. Consider what code you might need to write to support some other
extensions. Not just one extension, lots. Look for common features in
those extensions. I bet you'll find a lot of <link>-link structures.
All this is really about is expressing a very common data structure in
as unambiguous a fashion as possible.

> which to many would be unexpected.

How many of the current values for 'rel' in link would be appropriate
for hyperlinks? What about HTML's <link> element - does that come as a
surprise?

Cheers,
Danny.

---

From: Danny Ayers <[email-masked]>
Date: Wed, 25 Aug 2004 21:03:57 +0200

> consciously put an extensibility point around link types?

Exactly.

  If you want
> group wants to use them).  

I agree re. the qnames, but the horse has pretty well bolted, and I
think pragmatism beats purity here - it's easier than the RFC 2731
mechanism. In any case, if XHTML gets them, Atom will get them in its
content whether we approve or not.

I think the delic.io.us use-case throws a
> leaning would be for the former, but I can certainly see both sides of

The delic.io.us use-case is just the latest in a long series of
suggested additions to the 'rel' list. But in any case, we can have
both - add "about" to the core rather than as a (namespace-qualified)
extension.

Cheers,
Danny.

---

From: Antone Roundy <[email-masked]>
Date: Wed, 25 Aug 2004 13:11:01 -0600

On Wednesday, August 25, 2004, at 12:21  PM, Sam Ruby wrote:
> Let's see if I can capture that and see if there is a basis that we 
> can build upon.  With a mental model of something html link-ish 
> (leaving open the possibility to a number of tweaks), which of the 
> following can we agree upon?
>
This fits current syndication usage as far as I'm aware.  It's far from 
inconceivable that people could want to publish feed-only blogs rather 
than blogs with feeds, and that there could be other uses for feed-only 
publication, either of which may or may not not have links associated 
with each entry.

Perhaps a good question is, if an entry doesn't have a link--if it is 
entirely self-contained--does anything break?  Off the top of my head, 
I can't think of anything that that would really break.

> (2) Exactly one of those link elements is to be considered the 
> 'primary' or 'default' link.
Usually so. easy to conceive a case where there's not a 'primary' link, 
at least for the hypothetical feed-only blog.

> destination anchor defined by this attribute.
Sounds good.

> results with the mime type indicated by the type attribute.
I think it would be good to make it so that this is the case--anything 
that doesn't work this way should be in a  different element.

> (5) Exactly one of those link elements is to be considered a 
Only if we don't want to support feed-only publication, and don't want 
to require the ability to link directly to an atom:entry.

> (6) Linking to related articles is a valid use case for this element.
Yes.

> (7) Linking to sources is a valid use case for this element
Yes.  Question: do we want to be able to reference non-internet sources 
in a (semi)standard way?  For example,
<link rel="source" href="..." />
vs.
<source><link href="..." /></source>
vs.
<source><isbn>...</isbn></source>
vs.
<source><extension:isbn>...</extension:isbn></source>

> (8) Linking to comment feeds is a valid use case for this element
Yes to a link to the commen feed itself. The inteface for posting 
comments is a separate thing, covered by #10.

> (9) Linking to next/previous archives is a valid use case for this 
Yes.

> (10) Linking to service interfaces is a valid use case for this element
I'd prefer a different element be used for this.

---

From: Dan Brickley <[email-masked]>
Date: Wed, 25 Aug 2004 16:29:48 -0400

* Dare Obasanjo <[email-masked]> [2004-08-25 10:34-0700]
> and what is expected for consumers to do with that

OK I'll talk with the Nature folks and try to flesh this out. 

> open minded if you've already decided that 'RDF is the

(through gritted teeth) I said it's the only way *that I know of*.
(Right their, in the last sentence you read before responding. 7 lines up.) 

For better or worse, XML schema languages do tend to be more 
granular than the RDF approach; they typically define document types or 
element/attribute patterns that give us re-usable chunks of document. RDF 
is the only deployed approach *that* *I'm* *familiar* *with* where 
namespaces are typically mixed right in with each other in a well defined way. 
But I'm open to suprises; until I found http://www.itiran.com/?type=xml I
thought everyone put dates in their feeds, for example.

I most certainly don't think RDF is the only way to do this stuff.
But I do know that design by committee is a major risk in standards
work, and that known approaches are preferable to newly invented ones.
Which is why I'm cautious about Atom chewing up bandwidth and brains 
reinventing a wheel.
 
> not what you mean. So what do you mean? 

I mean having an architecture that offers guidance to the creators of 
those namespaces such that their products can be deployed directly 
alongside other namespaces without them having to have pairwise
agreements about whose elements can go inside whose. Not as sibling
elements each with their own subtree, but mixed right in with each
other, elements inside each other's, attributes on each other's
elements.

Dan

---

From: Eric Scheid <[email-masked]>
Date: Thu, 26 Aug 2004 08:51:28 +1000

On 26/8/04 3:21 AM, "Dare Obasanjo" <[email-masked]> wrote:

>> At the moment, the Atom link element is modelled after the HTML link tag[3],
>> which has a number of advantages[4].
>> 
> Yes, if all the links have similar semantics. Specifically what comes to mind
> is if as a fallback they can all be rendered as human clickable links. In
> fact, that simple guideline is probably all that is really needed in the Atom
> case. Although it will mean that for consistency that Atom shouldn't use
> atom:link for the various service URIs which doesn't seem like a bad tradeoff
> to me.
> 

+1

---

From: Eric Scheid <[email-masked]>
Date: Thu, 26 Aug 2004 08:55:58 +1000

> (1) Each atom:entry element must have one or more link elements

-0
 
> (10) Linking to service interfaces is a valid use case for this element
 
-1

---

From: Graham <[email-masked]>
Date: Wed, 25 Aug 2004 19:25:54 -0700

> The most immediate gains are disambiguation and code reuse.

This has already been completely debunked. The benefits here are 
minimal.

Graham

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 26 Aug 2004 08:17:19 +0200

On Wed, 25 Aug 2004 13:11:01 -0600, Antone Roundy <[email-masked]>  
wrote:

> This fits current syndication usage as far as I'm aware.

Syndication of ordinary blogs, yes. Syndication of absolutely all other  
types of resources on the web; no.

> It's far from inconceivable that people could want to publish feed-only
> blogs rather than blogs with feeds

Indeed.

> and that there could be other uses for feed-only publication, either of
> which may or may not not have links associated with each entry.

Or links associated with the feed. The feed and the entries will in such  
situations be the first-class resources and not just XML-wrappers for  
other resources. I would want to use Atom like that in many cases.

> entirely self-contained--does anything break?  Off the top of my head, I  
> can't think of anything that that would really break.

Me neither, so I see no reason to require that link; not for the feed and  
not for entries.

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Danny Ayers <[email-masked]>
Date: Thu, 26 Aug 2004 08:39:00 +0200

On Wed, 25 Aug 2004 19:25:54 -0700, Graham <[email-masked]> wrote:
> This has already been completely debunked.

No it hasn't, though you're welcome to try.
You get disambiguation because because the <link> structure is clearly
defined unlike adding arbitrary namespaced elements/attributes
anywhere. It allows code reuse because the same subsystem for
dispatching behaviour from core <link rel=..""> elements can be reused
to handle dispatching for other rel values. Using arbitrary namespaced
elements/attributes anywhere demands that for every new construct, new
code will be needed.

I honestly can't see why you have a problem with the notion of using a
common XML construct for a common range of data structures encountered
in syndication feeds.

 The benefits here are
> minimal.

That depends on specific requirements. I would like to use Atom for
more than simple news publishing/reading (or at least containing a
wider range of information, like the Nature feeds). In these
circumstances the benefits are great.

If you really believe that this approach doesn't offer any gain, then
it would be more productive if you could offer an alternative approach
to handling the kind of richness commonly found in RSS 1.0 feeds in
Atom in a systematic fashion. Or give a very good reason why Atom
shouldn't be able to do this - handling extensions is in the charter.

Cheers,
Danny.

---

From: Graham <[email-masked]>
Date: Thu, 26 Aug 2004 14:25:07 -0700

On 25 Aug 2004, at 11:39 pm, Danny Ayers wrote:

> to handle dispatching for other rel values.

else if (element.name=="link") {
	href=element.attr("href")
	rel=element.attr("rel")

	if (rel=="alternate") {
		alternate=href
	} else if (rel=="related") {
		related=href
	}
} else if (element.name="...") {

vs

else if (element.name=="alternate") {
	alternate=element.attr("href")
} else if (element=="related") {
	related=element.attr("href")
} else if (element.name=="...") {

Okay, so mine (the latter) repeats the attr("href"), which we haven't 
in yours (though it'd be easy enough to not repeat it). This is all the 
code reuse you get, because after that you have to do semantic-specific 
processing. That's why I say the benefits are minimal.

> common XML construct for a common range of data structures encountered

I have a common with using the element name as a type identifier. You 
can reuse the same construct if you like.

Graham

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 26 Aug 2004 14:54:23 -0700 (PDT)

+1

> processing. That's why I say the benefits are

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

---

From: Antone Roundy <[email-masked]>
Date: Thu, 26 Aug 2004 15:58:56 -0600

> } else if (element.name=="...") {
Examples can be constructed to make either way look simpler:

switch(element->name()) {
	case 'link':
		AddToLinksList(element->attr('rel'), element->attr('href'), 
element->attr('title'));
		break;
	...
}

vs.

switch(element->name()) {
	case 'alternate':
	case 'related':
	case 'start':
	case 'prev':
	case 'next':
		AddToLinksList(element->name(), element->attr('href'), 
element->attr('title'));
		break;
	...
}

As long as the element or elements all have the same structure (are all 
"Link Constructs"), I don't see that it makes a lot of difference until 
you start talking about extensibility.

---

From: Graham <[email-masked]>
Date: Thu, 26 Aug 2004 19:55:23 -0700

Exactly my point Antone.

Graham

---

From: Danny Ayers <[email-masked]>
Date: Fri, 27 Aug 2004 10:14:35 +0200

> can reuse the same construct if you like.

[typo?]

Looking at the code example, I'm not sure we actually disagree about
much here. I do think <link> in its current usage (with 20 or so
different possible rel values) is overly overloaded. I don't have any
problem with using similar constructs to better partition the
relationship space:

<related rel="homepage" href="" ...>
<alternate rel="printVersion" href=""...
<service rel="edit" href=""...

Or whatever, with the rel attribute (if needed) added a finer-grained
description to whatever the element covers. I also think it reasonable
to maintain a (short) list of allowable core values for rel.

But the utility I'm looking for is where the relationship isn't
defined in the core spec. Something like:

<link rel="tx:topic" href="http://some/category" title="the category" />

(Ok, no-one seems to like the use of qnames, I'm thinking of swapping
that for full URIs in the Pace)

The <link> element is just the most convenient in the current spec for
this treatment.

Take these two:

<entry>
<link rel="tx:topic" href="http://some/category" title="the category" />
</entry>

<entry>
<tx:topic href="http://some/category" title="the category" />
</entry>

On the surface, there's little to choose between them assuming the
link definition in the Pace, and the definition (somewhere) that child
elements are taken to apply to their parent.
But what about:

<entry>
<tx:topic href="http://some/category">the category</tx:topic>
</entry>

We simply don't have a consistent way of interpreting arbitrary
namespaced elements/attributes. The link construct offers a
constrained means of expressing a specific kind of relationship.

If the current link rel values were factored out into their own
elements then the same relationship structure could be used for other
non-core relationships, offering a bit more specificity:

<service rel="x:archive" ...>

But basically I really don't care how it's done, I just think there
needs to be a more systematic approach to extensions that putting
anything anywhere. Atom is expressed in structured markup, why not use
it?

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Danny Ayers <[email-masked]>
Date: Fri, 27 Aug 2004 10:14:35 +0200

[typo?]

Take these two:

<entry>

<entry>

<entry>

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Janne Jalkanen <[email-masked]>
Date: Fri, 27 Aug 2004 16:45:57 +0300

> Syndication of ordinary blogs, yes. Syndication of absolutely all 
> other  types of resources on the web; no.

Yeah.  The JSPWiki RSS/RDF feed currently has the latest diff of the 
page as the content of the entry.  This means that I already have a 
slight headache for thinking what my unique atom:id is going to be for 
them - after all, they are generated dynamically (no, I don't want to 
inflate a database with a wiki RecentChanges list).  The ID must contain 
references to the different version numbers, etc...

I was thinking of offering Atom feeds like "all differences from the 
last 24 hours" and "all diffs from the last week" or so, and I don't 
necessarily want to provide an HTML version of all the possible 
variants, as I can think of some uses which might be machine-readable 
only (like providing diffs to wiki pages which are consumed by a bot 
which keeps a duplicate of the wiki somewhere else, applying the diffs 
as they come along...  This might also mean that one might want to get 
an Atom feed with a timestamp: "please provide me changes from date 
XXYYZZHHMM onwards" using either some custom header or GET parameter 
trickery.)

I just think a syndication format should be able to stand on its own, 
without any references to external resources, that's all.  It would make 
Atom more attractive to machine-to-machine communication.

/Janne

---

From: Robert Sayre <[email-masked]>
Date: Fri, 27 Aug 2004 11:41:31 -0400

> Atom more attractive to machine-to-machine communication.

Take a look at PaceLinkDelicious. Currently, it requires "alternate". I 
could see requiring either "about" or "alternate", but not omitting 
both. After all, we're defining a format for syndication of Web 
resources[0].

Robert Sayre

[0] http://www.ietf.org/html.charters/atompub-charter.html

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 27 Aug 2004 21:46:55 +0200

> Atom more attractive to machine-to-machine communication.

I agree. Many (if not most) of my Atom usages will be machine-to-machine,  
not machine-to-human.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 27 Aug 2004 21:49:16 +0200

On Fri, 27 Aug 2004 11:41:31 -0400, Robert Sayre <[email-masked]>  
wrote:

> could see requiring either "about" or "alternate", but not omitting both.

Requiring «about» for feeds makes sense, or at least isn't very  
problematic. For entries, though, I think it's a problem. What's the use  
of having every atom:entry both inside the feed and on its own URI  
somewhere, when both are identical? E.g., the atom:entry inside the feed  
is the full representation that doesn't have a higher class alternative.

> After all, we're defining a format for syndication of Web resources[0].

Can't the atom:entry's inside atom:feed be syndicated directly? Do they  
need alternative representations (or «about» URI's) to be syndicable?