Subject: current status of source and/or via-link tracking syntax

From: Michael Frumin <[email-masked]>
Date: Mon, 01 Nov 2004 15:06:30 -0500

hi,

We're working on a new 1.0 release of our reBlog project 
(www.reblog.org) -- an online RSS/Atom Aggregator that is slanted 
towards republishing and resyndicating.  It does this by spitting out a 
feed that is consumed by plugins into standard blogging software 
(http://www.eyebeam.org/reblog is the first instance).

For our new release, we want to incorporate some of the atom syntax for 
indicating original source feeds and where'd-I-find-this Via links.  I 
have read thru a bunch of the conversation on this list relative to this 
topic but there didn't seem to be a real resolution.  Also Mark 
Pilgrim's nice tutorial of using <link rel="via"...> for linkblogging at 
http://diveintomark.org/archives/2004/05/27/howto-atom-linkblog offers 
somethning, but I don't see updates to the Atom specs that indicate the 
official way to do this.

SO, i was just wondering if someone could point me at a description of 
the current way in Atom to specify source feeds and Via links, I would 
appreciate it.  Also, we'll let y'all know when reBlog 1.0 is out (a 
couples weeks at most) and maybe someone out there cares to evaluate it.

thanks,
Mike Frumin
Research Fellow, Eyebeam

---

From: Robert Sayre <[email-masked]>
Date: Mon, 01 Nov 2004 16:14:47 -0500

Michael Frumin wrote:

> topic but there didn't seem to be a real resolution.  

We resemble that remark.

> appreciate it.  

For now, the version of Atom you should support is Atom 0.3, outlined here:

http://atomenabled.org/developers/

Newer versions should not be deployed, except for experimental purposes. 
Regarding "via" links and whatnot, I don't think there's an official 
position. Unfortunately, Atom 0.3 shipped with conflicting rules 
regarding link @rel values. The values outlined in Mark's article seem 
to be somewhat supported, but other values probably aren't for the 
moment. Consult atomenabled.org and feedvalidator.org for further 
information.

As for the *current* way, well, there isn't one. However, it looks like 
a great many link-related proposals will soon be meeting their end.

http://www.imc.org/atom-syntax/mail-archive/msg10800.html
http://www.intertwingly.net/wiki/pie/AtomPubIssuesList

Hope this helps,

Robert Sayre

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 1 Nov 2004 14:15:22 -0800 (PST)

> http://atomenabled.org/developers/

Personally, I think if you produce a tool that
generates Atom 0.3 feeds you are part of the problem
with XML syndication today. 

There is no reason to support an interim draft XML
syndication spec with a built-in expiration date
especially since this increases the fragmentation of
the XML syndication space. 

> The values outlined in
> Mark's article seem 
> moment.

What tools can consume via & source links as described
in Mark's article? None that I've heard of. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #222
I reserve the right to execute any henchmen who appear to be a little too intelligent, powerful, or devious. However if I do so, I will not at some subsequent point shout "Why am I surrounded by these incompetent fools?!"

__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com

---

From: Robert Sayre <[email-masked]>
Date: Mon, 01 Nov 2004 17:22:29 -0500

> with XML syndication today.

Personally, I think if you produce a tool that consumes Atom 0.3 feeds 
you are part of the problem with XML syndication today.

*yawn

The question was about Atom, the answer was about Atom.

> in Mark's article? None that I've heard of. 

I know magpie uses it. I don't know about other tools, but people seem 
to produce it.

Robert Sayre

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 1 Nov 2004 14:28:40 -0800 (PST)

--- Robert Sayre <[email-masked]> wrote:

> consumes Atom 0.3 feeds 

I don't disagree but thanks the boneheads at
Google/Blogger and the fact that all major aggregators
on Windows support Atom 0.3 (again thanks to the
Google/Blogger crowd) RSS Bandit does as well. We've
gone from complaining about 2 major flavors of XML
syndication (Dave Winer's specs & the RDF-based specs)
to 3 (Atom 0.3) with a fourth on the way (Atom 1.0). I
don't see why anyone who's interested in the growth of
this technology area would not feel dismayed at what
has happened in this space. 

Thankfully, I've been able to disuade the various
folks at work who've considered poisoning the XML
syndication well by emitting Atom 0.3 so far. The less
of these we have in the wild, the easier it will be to
wean people of them when Atom 1.0 ships. 

> The question was about Atom, the answer was about

I seem to remember one of the co-chairs of this
working group stating that the assumption of this
working group is that Atom 1.0 is the only version of
Atom that exists. Unless this policy has changed I
think your suggestion to use 'Atom 0.3' was contrary
to the spirit of this working group.  

=====

---

From: Robert Sayre <[email-masked]>
Date: Mon, 01 Nov 2004 17:35:34 -0500

> to the spirit of this working group.  

The only policy I know of is "tell people not to implement 
draft-format-nn." I did that. If there's some canned answer I'm supposed 
to give, someone enlighten me.

Robert Sayre

---

From: Michael Frumin <[email-masked]>
Date: Mon, 01 Nov 2004 19:04:02 -0500

thanks for the thoughts.  I think that for the moment, we'll do our best 
to receive atom feeds (vis magpie) but have decided to punt on producing 
them for the time being.  but we'll keep our ears to the ground for Atom 
1.0.

as i depart, i only have one thought which is to cast my vote, from a 
pragmatic standpoint, for some syntax to describe the chain of via-links 
further back than one degree.  in principle you should be able to just 
traverse the linked list, that might be a bit less practical than simply 
adding a little more payload to the Atom <entry>'s list of via links or 
whatever.

-mike

Robert Sayre wrote:

> draft-format-nn." I did that. If there's some canned answer I'm 
> supposed to give, someone enlighten me.
>
> Robert Sayre

---

From: Graham <[email-masked]>
Date: Tue, 2 Nov 2004 00:36:14 +0000

On 2 Nov 2004, at 12:04 am, Michael Frumin wrote:

> pragmatic standpoint, for some syntax to describe the chain of 
> via-links further back than one degree.  in principle you should be 
> able to just traverse the linked list, that might be a bit less 
> practical than simply adding a little more payload to the Atom 
> <entry>'s list of via links or whatever.

Unfortunately the chairs around here are obsessed with forcing all link 
metadata into a uniform data structure with zero flexibility wrt 
multiple links are a nested list. Never mind.

Graham

---

From: Eric Scheid <[email-masked]>
Date: Tue, 02 Nov 2004 12:02:29 +1100

> adding a little more payload to the Atom <entry>'s list of via links or

how about this:

    <link href="..." type="application/atom+xml" rel="via-list" />

which points to an atom feed where each entry refers to each hop in the via
list. essentially, leveraging the concept of attaching a feed of comments to
an entry.

this way you get more bang for the buck, while not overburdening those
aggregators that are not interested (only one link to download and then
ignore).

e.

---

From: Tim Bray <[email-masked]>
Date: Mon, 01 Nov 2004 17:26:06 -0800

On Nov 1, 2004, at 4:36 PM, Graham wrote:

> Unfortunately the chairs around here are obsessed with forcing all 
> link metadata into a uniform data structure with zero flexibility wrt 

Calm down, Graham.  Both Paul and I would be perfectly happy with 
several of the link-generalization options that have been thrown 
around, and neither of us would stand in the way of consensus.  The 
brutal truth is that consensus in this group on this subject is notable 
by its absence, thus the extremely impoverished state of the atom:link 
in the current drafts.  -Tim

---

From: Graham <[email-masked]>
Date: Tue, 2 Nov 2004 14:17:38 +0000

On 2 Nov 2004, at 1:26 am, Tim Bray wrote:

> brutal truth is that consensus in this group on this subject is 
> notable by its absence, thus the extremely impoverished state of the 
> atom:link in the current drafts.

Q: Who is actually pushing for extensions that happen to contain URIs 
to be recognizable?

Graham

---

From: Sam Ruby <[email-masked]>
Date: Tue, 02 Nov 2004 10:07:14 -0500

Graham wrote:

> Q: Who is actually pushing for extensions that happen to contain URIs to 
> be recognizable?

Which Pace are you referring to?

- Sam Ruby

---

From: Graham <[email-masked]>
Date: Tue, 2 Nov 2004 15:17:47 +0000

> Which Pace are you referring to?

Cute. Now answer the question.

(Requiring spec text to be written before ideological issues have been 
settled was the worst thing this group's ever done btw)

Graham

---

From: Robert Sayre <[email-masked]>
Date: Tue, 02 Nov 2004 10:45:58 -0500

>>> Q: Who is actually pushing for extensions that happen to contain URIs 

Everyone except you, near as I can tell. I can't find anyone in the 
archives besides yourself squwking about this issue. People already want 
to create their own. It's not hard to find feature requests.

I support PaceFieldingLinks. Is this a problem to implement in your 
software?

Robert Sayre

---

From: Graham <[email-masked]>
Date: Tue, 2 Nov 2004 15:59:58 +0000

On 2 Nov 2004, at 3:45 pm, Robert Sayre wrote:

> archives besides yourself squwking about this issue.

I don't think everyone does support it, I think they just aren't 
bothered. I can't think of anyone who would be upset if the 
extensibility within the link element was removed. The only people I've 
seen say as a good idea didn't seem too enthusiastic - they seemed to 
be saying it on behalf of someone else, ie "I guess someone might find 
that useful". That bothers me, because the lack of consensus here is 
mostly being caused by how to implement a feature no one is too 
bothered about.

> People already want to create their own. It's not hard to find feature 
> requests.

Why can't they use new or namespaced elements like every other 
extension type? Dates don't have a rel mechanism, for example.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Tue, 02 Nov 2004 11:20:19 -0500

Graham wrote:
> extensibility within the link element was removed.

Except for all the people that support it, which is everyone who's 
spoken on the issue except yourself. We already have people creating 
stuff like "via", "related", "about", "enclosure". We didn't foresee any 
of those in Atom 0.3. They have additional semantics, but they also make 
perfect sense as a plain old link.

> Why can't they use new or namespaced elements like every other extension 
> type? 

They could, but prior art shows us that treating links specially is 
worth it.

How about you answer my question. What problem does PaceFieldingLinks 
pose for your software? How does it hurt interop?

Robert Sayre

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 2 Nov 2004 11:22:14 -0500

Michael Frumin wrote:
> indicating original source feeds and where'd-I-find-this Via links.

Please consider:
http://www.intertwingly.net/wiki/pie/PaceHeadInEntry

This is an update to the practice that we follow today with all PubSub.com
feeds.[2] For each entry/item that we republish, we copy the source feed's
"feed-metadata" into an element named "ps:source-feed" (in both RSS and
Atom). The idea is that when an entry is extracted from a feed, it should be
accompanied by those parts of the source-feed's meta-data that are important
for interpreting the entry or placing it in context. We are *really* hoping
that this gets into Atom V1.0 and will change from ps:source-feed to
atom:head when that change occurs.

I expect that the "Atom over XMPP"[1] specification will be modified to
support PaceHeadInEntry once/if the WG accepts it.

The issue of "via" links is not addressed in PaceHeadInEntry.

		bob wyman

[1]
http://www.ietf.org/internet-drafts/draft-saintandre-atompub-notify-01.txt
[2] For a sample feed consider either of the following:
http://rss.pubsub.com/0a/46/66f253a3dfea0cef64ede47ddd.xml
http://atom.pubsub.com/0a/46/66f253a3dfea0cef64ede47ddd.xml

---

From: Antone Roundy <[email-masked]>
Date: Tue, 2 Nov 2004 10:01:39 -0700

On Tuesday, November 2, 2004, at 09:20  AM, Robert Sayre wrote:
> stuff like "via", "related", "about", "enclosure". We didn't foresee 
> any of those in Atom 0.3. They have additional semantics, but they 
> also make perfect sense as a plain old link.
>
Yes, exactly.  Suggestions for new @rel values keep popping up (many of 
which make sense as a plain old link...though some don't), which 
strongly suggests to me that we may not have thought of all of them 
yet, that we may not think of all of them by the time atom 1.0 is 
finished, and that WE may never think of all of them.  Thus, leaving an 
opening for whoever DOES think of them to get them in seems like a good 
idea.

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 2 Nov 2004 12:04:07 -0500

Graham wrote:
> Unfortunately the chairs around here are obsessed with forcing
> all link metadata into a uniform data structure with zero
> flexibility wrt multiple links are a nested list. Never mind.

	Just to confuse matters a bit, I'd like to suggest that folk take a
look at the RDF/A Syntax[1] which may be useful for us in general while also
making the RDF folk a bit happier then they otherwise might be. RDF/A
provides a means for layering RDF information on any XML document by
defining a new XML syntax for RDF that relies only on XML attributes. 
	Given that many of the things that people want to do with the
proposed extensions to atom:link look very "RDF-like", it might be useful to
rely on a proposal that comes from RDF-land...

	For an example of something that you can do with recognizable links
in an environment that assumes the ability to scan large quantities of feeds
for interesting bits of data (using PubSub, Feedster, Technorati, etc.) take
a look at what Technorati has implemented to track "votes"[2]. (A
particularly relevant capability today...) 
	Technorati supports:
<a rel="vote-for" href="http://www.johnkerry.com">John Kerry</a> 
<a rel="vote-against" href="http://www.georgewbush.com">George Bush</a>

	Also, consider what I[3] and others[4] have suggested in the past as
a useful way of linking entries to topics, ideas, categories, etc.

		bob wyman

[1] http://www.formsplayer.com/notes/rdf-a.html
[2] http://developers.technorati.com/wiki/VoteLinks
See vote results at: http://www.technorati.com/live/votes.html
[3] http://bobwyman.pubsub.com/main/2004/02/making_categori.html
[4] http://matt.blogs.it/specs/ENT/1.0/ (Easy News Topics)

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 2 Nov 2004 09:15:19 -0800 (PST)

--- Graham <[email-masked]> wrote:
> The only people I've 

Moving specs forward is about compromise.
PaceFieldingLinks hits the sweet spot in simplicity
and satisfying the various folks who want link
extensibility. 

If this gets the working group past arguing about link
extensibility then it is all goodness. 

=====

---

From: Tim Bray <[email-masked]>
Date: Tue, 02 Nov 2004 09:25:01 -0800

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

Would it be an oversimplification to say that this provides by value 
what atom:origin provides by reference? -Tim

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 2 Nov 2004 13:36:55 -0500

Tim Bray wrote:
> Would it be an oversimplification to say that [PaceHeadInEntry]
> provides by value what atom:origin provides by reference? -Tim
	It would be an incorrect simplification. An atom:origin is an
atom:id, thus, it is not a "ref" it is an "id" and can't be reliably
dereferenced[1]. You can't use atom:origin to discover the contents of the
atom:head for the feed within which an atom:entry was published unless
you've either seen the feed before or are able to use some service that
would map from the id to a ref (URL) or would serve up just the feed head
data. (I am unaware of any such service and while we might build such a
thing, I don't think the utility of Atom should depend on it.)
	Also, atom:id is an *optional* element of the feed's atom:head.
Thus, an aggregator may not always be able to construct an "atom:origin"
element for the feed without inventing a new atom:id (which would be a bad
thing.)
	PaceHeadInEntry is particularly important for aggregate/synthetic
feed providers since a high proportion of the entries presented to the
reader of an aggregate feed will come from feeds that the reader has never
seen before. Even if a service existed to do id-to-ref or head lookups, it
would still be undesirable to use atom:origin in this application since
clients would end up generating a very large number of lookup calls to the
service. 

		bob wyman

[1] draft-ietf-atompub-format-03.txt at 3.6.1

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 3 Nov 2004 20:34:51 -0800

> defining a new XML syntax for RDF that relies only on XML attributes.

Yikes, no, Qnames have no meaning inside content -- they are
only processed by the XML parser.  If they are inside the attribute
value then the attribute value reader must backtrack through the
XML tree in order to rediscover the Qname -> namespace URI mapping,
which is kind of hard to do given that attribute value readers
tend not to be XML parsers and don't have access to the tree
(unless they happen to be an XSLT application).

> rely on a proposal that comes from RDF-land...

That doesn't come from RDF land -- it is a Note by two authors.

....Roy

---

From: Henry Story <[email-masked]>
Date: Tue, 16 Nov 2004 18:05:20 +0100

> thing, I don't think the utility of Atom should depend on it.)

Yes but what if we invented an atom:origin2 which allowed you to put 
the entire
contents of the head of the feed into the origin2 slot. Then you would 
have what Tim Bray was mentioning an atom:origin that would allow you 
to provide your header by value. Which pretty much is what you are 
proposing it seems.

> 	Also, atom:id is an *optional* element of the feed's atom:head.

Also one could make it non optional. But that is not a problem because 
we are not
speaking about atom:origin, but about atom:origin2 where you can pass 
your arguments by value.

> clients would end up generating a very large number of lookup calls to 

Again there you are not replying to Tim's point. You are saying so and 
so is the
case with atom:origin as it is currently. Tim was asking if what you 
were proposing was not something like atom:origin2.

If it is something like atom:origin2 then atom:origin2 would fulfill 
your needs just as well, no?

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 16 Nov 2004 12:57:20 -0500

Henry Story wrote:
> you are not replying to Tim's point. You are saying so and so is
> the case with atom:origin as it is currently. Tim was asking if
> what you were proposing was not something like atom:origin2.
	I don't see that. "atom:origin2" is your invention, not Tim's. Tim
referred to "what atom:origin provides by reference." I was pointing out
that atom:origin provides nothing "by reference" in that it doesn't pass
anything which can be de-referenced. Thus, you "Can't get there from here"
using atom:origin as defined -- if where you're trying to get is the feed
that was the "origin" for the entry. 
	If atom:origin had been defined as an URL, I would have agreed that
"PaceHeadInEntry provides by value what atom:origin provides by reference."
But, atom:origin isn't a re-referenceable URL so the answer to Tim's
question is "No. It ain't so!"

		bob wyman

---

From: Henry Story <[email-masked]>
Date: Tue, 16 Nov 2004 19:58:13 +0100

On 16 Nov 2004, at 18:57, Bob Wyman wrote:
> anything which can be de-referenced.

You are being very finicky here, and mistakenly so too. Atom origin 
points to a *URI*. That it can not necessarily be dereferenced 
mechanically is not a criterion for saying that it does not refer to 
the head by reference.

> Thus, you "Can't get there from here"

Ok. So if I tell you to read the book with ISBN URI say 
urn:ISBN:0-198-24686-2
which is a really good book by Gareth Evans called "The Varieties of 
Reference"
you are going to tell me that I did not pass you the book by reference?

I don't see how you can argue that position, frankly.

---

From: Antone Roundy <[email-masked]>
Date: Tue, 16 Nov 2004 12:11:34 -0700

> you are going to tell me that I did not pass you the book by reference?
If you don't tell me where I can find a copy of the book, and I can't 
find it myself, then knowing it's ISBN number doesn't help me get 
information out of the book.

And unless an atom:feed's ID changes whenever the contents of its 
atom:head changes (as I believe a books ISBN would change if a new 
edition were released, right?), then the ID, or even the URL of the 
feed, would not provide a reliable pointer to the context of the entry. 
  (To which you might well reply that the entry might still appear in 
the feed after atom:head changed, so it's context SHOULD change, to 
which I might well reply that the entry MIGHT get deleted in connection 
with the change to atom:head, just like some text might get deleted 
from a new edition of a book...so who knows).

---

From: Henry Story <[email-masked]>
Date: Tue, 16 Nov 2004 21:16:56 +0100

> information out of the book.

Ok. And if I pass you the URL of a book, and by the time you decide to  
act on it, the page is down, or the server is gone, then I also did not  
pass you the book by reference?

> edition were released, right?),

Ah ok. Just add a version id to every Entry and every feed.

	Entry1 ---versionId--->tag://bblfish.net/entry1#version1

> then the ID, or even the URL of the feed, would not provide a reliable  
> pointer to the context of the entry.

Ok! I see what you mean by the context of an Entry! Thanks! You mean  
the Feed version in which it appeared. Or rather the version of the  
Entry that is the head of the feed (in PaceEntriesAllTheWayDown2  
language)

> which I might well reply that the entry MIGHT get deleted in  
> connection with the change to atom:head, just like some text might get  
> deleted from a new edition of a book...so who knows).

Yes, but all that said and done, you are doing what origin would do if  
it pointed to the feed version, but you are passing the contents of the  
origin head by value (ie, you are just copying the contents of the head  
into the <origin>..</origin> tag)

> what atom:origin provides by reference? -Tim

Ok. So the oversimplification is only that atom:origin does not use a  
version construct. If it did, there would be no oversimplification in  
saying what Tim Bray said.

Ie. you could fill the contents of
	<origin>
		
	</origin>
with whatever you found in the head, when you fetched the feed.

There would be no more problem popping an Entry content in there as  
there would be popping the contents of some HEAD structure.

------------------------------ 
Conclusion--------------------------------------------
So my PaceEntriesAllTheWayDown2 does not in any way hinder Bob in his  
work aggregating disparate feeds.
------------------------------------------------------------------------ 
------------

Henry Story

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 16 Nov 2004 16:11:55 -0500

Henry Story wrote:
>Tim Bray wrote:
>> Would it be an oversimplification to say that this provides by
>> value what atom:origin provides by reference? -Tim
> version construct.
	What you are saying is that Tim would not have been oversimplifying
if only he had said something that he did not say.

	As much as you may wish to avoid the point, atom:origin does *not*
pass data by reference. The atom:id is explicitly defined in the Atom spec
as being something that can not be dereferenced -- even though it is noted
that it sometimes might be. This is not like a "broken URL." URLs are
intended to be dereferenceable and we say they are "broken" if they aren't
derefenceable. However, an atom:id is not "broken" if it can't be
dereferenced since there is neither a guarantee nor an expectation that you
should be able to dereference an atom:id.
	What we may be distinguishing here is a third, and not terribly
useful way of passing data... Consider that we have:
	1. Pass by value (real bits)
	2. Pass by reference (via an URL)
	3. Pass by ID (via a URI that can't be dereferenced.)
	That third form, "pass by id" is simply not very useful in most
situations even though it does have utility in some situations. Nonetheless,
it ain't "pass by reference."

		bob wyman

---

From: Martin Duerst <[email-masked]>
Date: Wed, 17 Nov 2004 07:57:35 +0900

>And unless an atom:feed's ID changes whenever the contents of its 
atom:head changes (as I believe a books ISBN would change if a new edition 
were released, right?),

This is just hearsay from some of the URN debates, but as far as I
understand, ISBNs get reused, sometimes for new editions, and sometimes
for totally different books (assuming the old one is out of print).
Allocation is up to the publisher, and what an edition is is also
more or less up to the publishers (there are things such as
major and minor editions, printings, and so on).

I'm sure there are some people on this list who know better.

Regards,   Martin.

---

From: "S. Mike Dierken" <[email-masked]>
Date: Tue, 16 Nov 2004 19:27:01 -0800

> atom:head changes (as I believe a books ISBN would change if a new edition
New editions often have new ISBNs. But not always.

> for totally different books (assuming the old one is out of print).
Yes, that is true.

> I'm sure there are some people on this list who know better.
Yep. Sometimes an ISBN is used by a publisher for a pre-release of a book
that isn't actually published & the ISBN is re-used. This causes all kinds
of havoc at Amazon, but we've got tools & systems that validate/verify &
attempt to double check this sort of issue.

Similar problems happen with UPCs. For example, many toys have different
models yet use the same UPC (Rescue Heroes is an example). This causes
problems when a warehouse receives an item, scans the UPC & has several
choices - the pink Barbie or the purple Barbie...

If you really want to know more details on ISBN I can ask around & get more
specifics.

---

From: Henry Story <[email-masked]>
Date: Wed, 17 Nov 2004 10:39:18 +0100

Yes, as I said you are splitting hairs here. You have identified 1 way 
to pass by value, and 2 ways to pass by reference. Under one of the 
interpretations of passing by reference (which you call passing by ID), 
it is true to say that what you are proposing is a pass by value 
version of what atom:origin passed by id-reference. With the important 
proviso that the reference should be a Feed version reference.

Ok. So what is the point of my pointing this out?

1. With a slight reworking of atom:origin it would do what you are 
proposing to do with atom:head
2. By insisting on calling it atom:head you are trying to identify an 
entry metadata with the feed metada. This was very well explained by 
Antone Roundy [1]
3. I find the model on which you are basing your idea [2] very 
difficult to follow [3], not to say incomprehensible.

((You argue that your inability to model this in UML is due to the 
limitations of UML and the restrictions imposed on the xml format [4]. 
But this is doubly suspicious. There are ways around this. One such is 
to build a model that is more powerful than what Atom currently allows 
and then simply to add restrictions later. If UML is not good enough, 
first order logic would also do. Another solution is OWL, which can be 
mapped onto set theory, so modelling in OWL inherits that precision.))

Henry Story

[1] http://www.imc.org/atom-syntax/mail-archive/msg11662.html
[2] propounded here
	http://www.imc.org/atom-syntax/mail-archive/msg11639.html
[3] http://www.imc.org/atom-syntax/mail-archive/msg11644.html
[4] http://www.imc.org/atom-syntax/mail-archive/msg11653.html