Subject: Posted PaceDeclareVictoryOnFormat

From: Tim Bray <[email-masked]>
Date: Mon, 08 Nov 2004 14:13:17 -0800

See http://www.intertwingly.net/wiki/pie/PaceDeclareVictoryOnFormat

The world can use Atom, sooner rather than later.  The 
return-on-investment of further WG time invested in polishing something 
that's already pretty good is starting to be very unattractive.  
Particularly when the Protocol draft seriously needs work and progress.

Note that this has not been formally placed at the front of the queue 
yet.  -Tim

---

From: Robert Sayre <[email-masked]>
Date: Mon, 08 Nov 2004 17:28:23 -0500

> Particularly when the Protocol draft seriously needs work and progress.

I would go for it, assuming judgment on a couple things currently in the 
queue:

PaceFieldingLinks (people are already using their own rel values)
PaceUpdatedDefinition (2 dissenters?)

That leaves extensibility RSS2-style loose, which I don't particularly 
like, but I can live with it.

Also, there's PaceProvideSchema.

Robert Sayre

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 8 Nov 2004 14:44:20 -0800 (PST)

--- Tim Bray <[email-masked]> wrote:

> See
http://www.intertwingly.net/wiki/pie/PaceDeclareVictoryOnFormat
> Particularly when the Protocol draft seriously needs

-1 

So far Atom is a less featureful version of RSS 2.0. I
was actually thinking about that this weekend while
reading Charles Miller's post at
http://fishbowl.pastiche.org/2004/11/08/finally_a_use_for_atom
and realizing that my internal data models in RSS
Bandit haven't changed one whit because of Atom, just
the parsing code.  

As it stands now given the current cost/benefit of
Atom over RSS 2.0, the current Atom draft + categories
isn't something I'd advise anyone at my employer's to
use if it became an RFC nor is it something I believe
we'd use on the stuff I work on directly
(http://spaces.msn.com for one). 

=====
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: Bill de hÓra <[email-masked]>
Date: Mon, 08 Nov 2004 22:55:35 +0000

> Particularly when the Protocol draft seriously needs work and progress.

I agree, but - it's arguable that dates and links are just not 
coherent, which makes me doubt the spec is good enough.

> Note that this has not been formally placed at the front of the queue 

I suggest gathering some of that consensus stuff first ;)

cheers
Bill

---

From: Danny Ayers <[email-masked]>
Date: Tue, 9 Nov 2004 00:06:45 +0100

> > See http://www.intertwingly.net/wiki/pie/PaceDeclareVictoryOnFormat

It would be very much in my personal interests to agree with this -
writing about this stuff as a fixed target would be great, it wouldn't
really matter too much if Atom was less than RSS 2.0 or 1.0. But after
the effort that's gone into this project so far I can't help but think
it's worth going the last couple of miles.

There are 6 Paces currently under discussion, on a couple of these at
least consensus is uncertain. There are a further 40 or so more in the
queue. There is at least one systematic lack, that of extensibility.

Declaring victory now would be a betrayal of the front-line troops,
leaving them at the mercy of insurgent bugs...

-1

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Sascha Carlin <[email-masked]>
Date: Tue, 09 Nov 2004 00:23:11 +0100

> So far Atom is a less featureful version of RSS 2.0.

As a bystander, throwing in only some words at a time, I have the 
feeling that many good ideas and features got kicked out because there 
is no _current_ usage.

And that is, as I have already said on the list, no good. See 
<http://www.imc.org/atom-syntax/mail-archive/msg07773.html>

Of course Atom now is more or less stable enough and could replace RSS 
and its many brothers and sisters. But, as Dare states it, there is no 
benefit to it.

Well, this is more of a political discussion than a technical question, 
but is is worthwhile to think about it. What do we want to achieve and 
what do we provide for the future? Yeah, I know, there is the charter 
answering these questions, but beside the charter there is a emotional 
side, too, ain't it?

I am really sorry my English is not good enough to actually say what I 
want to say, but that should be at least understandable.

cu, Sascha

---

From: Graham <[email-masked]>
Date: Mon, 8 Nov 2004 23:45:07 +0000

You may want to, but you and Sam and Paul have promised too many people 
that things would be revisited later. I, as you may have noticed, think 
the spec sucks in many many places, but more than that I was under the 
impression that there would be time to revisit and reword and rearrange 
things after the content of the spec has been finalized. Are we not 
bothering with that?

Graham

---

From: Tim Bray <[email-masked]>
Date: Mon, 08 Nov 2004 15:53:12 -0800

> So far Atom is a less featureful version of RSS 2.0.

Atom as currently specified has the following advantages over RSS:

1. There's zero ambiguity about single and double escaping, you can use 
whichever suits your publication process better and not worry about 
silent data loss.
2. You can include binary chunks right there in-feed, base64 encoded.
3. You get help for aggregate feeds using atom:origin
4. You have a date, atom:updated, with cleanly-specified semantics 
("publisher says something changed") that's *guaranteed to be there* 
per-entry
5. It's in an XML namespace
6. It's got a good accessibility story: you have to have an 
atom:summary if there's no src= or it's binary.
7. You have clean semantics for linking to the entry this describes or 
the entry it's talking about.

Personally, I think these are highly significant.  But even if you 
disagreed, there are two other reasons why it would be good to get the 
Atom format spec finished:

1. Atom has an official specification change-controlled by a 
highly-independent standards org, there is no suspicion that any vendor 
or individual is pulling the strings.  This might not strike you as 
important, but I assure you that there are lots of people to whom it 
is.
2. The atom format is one foundation of the Atom publishing protocol, 
and I guarantee that the world can *really* find a use for the 
protocol.

Also as regards RSS2 and Atom, my take was that the things in RSS2 that 
aren't in Atom are widely-unimplemented and thus better omitted (that's 
how we got from SGML to XML).  I thought <category> was widely-used, 
but I was wrong.  Is there anything in RSS2 that we don't have but is 
in wide use?  -Tim

---

From: Henry Story <[email-masked]>
Date: Tue, 9 Nov 2004 02:21:57 +0100

Perhaps what should be done is not so much declare victory on the 
format, but move everyone to help solve the problems with the atom API 
that seems currently to be completely at a standstill.

There is a mailing list available to discuss that topic at
http://www.imc.org/atom-protocol/index.html

Let's perhaps slow down the movement on the syntax front and move to 
completing the API side of things. That way we can use the API to help 
polish the syntax.

Henry Story

On 8 Nov 2004, at 23:13, Tim Bray wrote:

> return-on-investment of further WG time invested in polishing 
> something that's already pretty good is starting to be very 
> unattractive.  Particularly when the Protocol draft seriously needs 
> work and progress.
>

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 8 Nov 2004 18:11:19 -0800 (PST)

> whichever suits your publication process better and

Given the recent clarification of the <description>
element by Dave Winer the only ambiguity left in RSS
is with titles. This isn't to say there are no issues
(the MSN Spaces team just hit this problem last week
where an escaped title showed up fine in RSS Bandit
but looked bad in another aggregator) 

> 2. You can include binary chunks right there

Who actually wants this feature? People are already
complaining about RSS bandwidth costs now let alone
when feeds contain binary content that has been
bloated to twice or thrice its size by base64
encoding. 

> 3. You get help for aggregate feeds using

Sounds like  the <source> element in RSS 2.0 

> ("publisher says something changed") that's

This is the first real new capability you've listed so
far. 

> 5. It's in an XML namespace

So? 

> atom:summary if there's no src= or it's binary.

You can use <description> in RSS 2.0 and there's no
option for having just binary inline content.  

> the entry it's talking about.

Really? I thought that wasn't resolved yet. 

> Atom format spec finished:

I don't. Two minor features is not cause enough for
doubling the amount of widely used XML syndication
formats on the Web (Dave Winer's specs + RDF-based
specs + Atom 0.3 + Atom 1.0). This is from my
perspective as an aggregator author and as someone who
works for vendor of a hosted blogging solution (Note:
I'm not representing Microsoft on this list). 

> important, but I assure you that there are lots of

Some of us are above personality squabbles when it
comes to deploying and implementing technologies. The
fact that Dave Winer is responsible for RSS 2.0 and
has flamed myself and my employer doesn't change the
fact that I and Microsoft have adopted it widely. 

> and I guarantee that the world can *really* find a

True. As redundant as the Atom syndication format is,
I think there is some value in the Atom API especially
with regards to security. Then again, I've toyed with
just seeing how hard it would be to get vendors of
blog posting tools to just support XML-RPC over HTTPS.

> in wide use?  

Your mistake is thinking that stuff in the RSS 2.0
spec is all that RSS is about. 

=====

---

From: Eric Scheid <[email-masked]>
Date: Tue, 09 Nov 2004 13:42:19 +1100

> the entry it's talking about.

8. multiple <link> children allowed, with attributes to distinguish them
from each other. Thus we can have 'via' links, 'about' links, and more (vs
the confusion which is <link> vs <guid>)

9. improved granularity by content/@src, reducing bandwidth costs.

e.

---

From: Robert Sayre <[email-masked]>
Date: Mon, 08 Nov 2004 21:54:47 -0500

Dare Obasanjo wrote:

> is with titles. 

An interesting assertion. Care to comment on the cardinality of RSS2 
elements? I seem to recall recent debate on the number of enclosure 
elements allowed in an entry.

> option for having just binary inline content.  

There's an option for summaries and full content in Atom. Witness 
content:encoded in RSS1 and the use of atom:content and xhtml:body in 
RSS2. There's no option for content @src in RSS2, other than using 
atom:content.

> fact that I and Microsoft have adopted it widely. 

Tim said "suspicion." This doesn't have anything to with Dave (who I 
just met at Bloggercon and found to be a pretty cool guy). Discomfort 
with the home of the RSS2 spec is not a personality squabble.

Robert Sayre

---

From: Joe Gregorio <[email-masked]>
Date: Mon, 8 Nov 2004 21:10:53 -0500

> completing the API side of things. That way we can use the API to help

+1 to working on the protocol and using it to polish the format.

-1 to PaceDeclareVictoryOnFormat since we are missing:

1. Any mention of extensibility in the format spec.
2. A feed level 'image' element, ala RSS 2.0 which, "Specifies a GIF, 
   JPEG or PNG image that can be displayed with the channel."

   -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 8 Nov 2004 19:28:36 -0800 (PST)

> elements allowed in an entry.

The spec implies that the cardinality is zero or one
but I could see how some language lawyer could claim
it is ambiguous. 

What I find funny about people that complain about RSS
is that they always use the "asshole argument". If the
spec doesn't explicitly disallow something that is
implied to be disallowed then they make a hue and cry
about how it is broken. 

As someone who's actually worked with a number of W3C
specs that contain stuff that is just plain broken I
find the so-called issues people have with RSS to
extremely minor nitpicks. 

> RSS2. There's no option for content @src in RSS2,

RSS 2.0 has enclosures which make a lot more sense
than <content src=""> in syndication scenarios. Also
I've seen RSS 2.0 feeds that use content:encoded so
I'm not sure where you get the idea that its usage is
restricted to RSS 1.0 

> with the home of the RSS2 spec is not a personality

Really, who are the people that have this discomfort
who aren't people who've had personality conflicts
with Dave Winer? The major folks I've seen making a
hue and cry about this are the Blogger and Six Apart
folks who've beefed with Dave Winer. 

PS: Quite frankly I'm not even sure why I'm opposing
this Pace. It would be amusing to watch if after all
the hubbub about Atom all it ended up being was a less
featureful but more complex clone of RSS.  

=====

---

From: Robert Sayre <[email-masked]>
Date: Mon, 08 Nov 2004 22:37:33 -0500

> implied to be disallowed then they make a hue and cry

That's fine. It is often good practice to leave aspects of a spec 
undefined. What's not OK is to "clarify" them without revving the spec.

> than <content src=""> in syndication scenarios. 

Just why is that? I see a use for enclosures, and

> Also

It's defined as an RSS1 module (which includes indirection, BTW). You 
can validly put it in RSS2, but its meaning would be undefined there.

Robert Sayre

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 8 Nov 2004 19:48:11 -0800 (PST)

> without revving the spec.

Someone should explain that to the W3C then since that
is standard practice there. Of course, this is a lot
better than the IETF which just abandons specs once
they throw them out there. Trying to figure out how to
implement NNTP support from the relevant IETF specs
was a joke given how far practice had outpaced the
much outdated RFCs. 

Like I said, as someone who's spent the past few years
working with specs produced by standards bodies I find
the complaints about RSS 2.0, etc to consist mainly of
nitpicking. 

=====

---

From: Robert Sayre <[email-masked]>
Date: Mon, 08 Nov 2004 23:09:48 -0500

>>without revving the spec.

I'm going to assume you agree with me. I guess?

Unrelated:
> is standard practice there. 

Unrelated:
> Of course, this is a lot

That's a nice opinion. Of course, you've already stated as much, so I'm 
not sure why you're repeating yourself.

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Tue, 09 Nov 2004 15:05:47 +1100

>> 5. It's in an XML namespace

So you can use Atom elements in other formats if you want to. Just as it's
possible to use dc:subject and content:encoded in lots of different places.
Without a namespace this isn't so easy.

If I wanted to use RSS 2.0 enclosures in an atom feed, how would I write it?

e.

---

From: Martin Duerst <[email-masked]>
Date: Tue, 09 Nov 2004 13:19:44 +0900

>bloated to twice or thrice its size by base64

Bloated by a factor 1.33333... to be exact.
It may still be bad, but there is no reason to
exagerate it.

Regards,    Martin.

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 8 Nov 2004 20:40:52 -0800 (PST)

> I'm going to assume you agree with me. I guess?

I wonder where you got that idea? 

No public standards body I am aware of isn't guilty of
this today. The IETF (which Atom will be published
under) has a particularly nasty habit of not even
bothering to update specs at all which is a LOT WORSE
than updating them without revving the spec. 

How to deal with errata to specs is a problem that no
one has really figured out how to solve yet. Remove
the log from your own eye and all that... 

=====

---

From: Tim Bray <[email-masked]>
Date: Mon, 08 Nov 2004 20:54:10 -0800

On Nov 8, 2004, at 6:11 PM, Dare Obasanjo wrote:

> formats on the Web
...
> As redundant as the Atom syndication format is,
> I think there is some value in the Atom API

Dare, you may regard this effort as redundant, but I see it as my role 
to help ensure that this WG ships something that is acceptably 
feature-ful in an acceptable time-frame.  Obviously there are 
trade-offs.  You are explicitly saying that you don't think the Atom 
format is ready.  Please outline for us which set of features you would 
consider it necessary that Atom have to be worth doing.  Are they 
represented by existing Paces?  If not, do you plan to create some 
covering the missing pieces?  -Tim

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Tue, 9 Nov 2004 08:07:30 -0500

> -----Original Message-----
> From: Dare Obasanjo [mailto:[email-masked]] 
> Sent: Monday, November 08, 2004 11:41 PM
> To: [email-masked]
> Cc: Tim Bray; Atom WG
> Subject: Re: Posted PaceDeclareVictoryOnFormat

[snip]

> than updating them without revving the spec.

This is an artifact of the IETF "membership" (perhaps more accurately
described as the "lack of formal membership") structure.  If no one is
willing to volunteer to do the work, the specs don't get updated.  The
positive aspect of this structure is that *anyone* who has an interest in
the topic can step up to the task if they wish.  It just takes someone
willing to make the commitment.

Yes, this sometimes means that implementers do their own thing when the need
arises and no one has the interest or energy to work on the specs.  It's a
part of the culture that we recognize and try to deal with when people *do*
express enough interest.

-Scott-

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 9 Nov 2004 08:57:35 -0500

At 11:45 PM +0000 11/8/04, Graham wrote:
>You may want to, but you and Sam and Paul have promised too many 
>people that things would be revisited later. I, as you may have 
>noticed, think the spec sucks in many many places, but more than 
>that I was under the impression that there would be time to revisit 
>and reword and rearrange things after the content of the spec has 
>been finalized. Are we not bothering with that?

We are bothering with that right now; that's the purpose behind the call.

Please list the specific "to be revisited" that you think are 
important for the core of Atom. If there is agreement in the WG, we 
will definitely work on them.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 9 Nov 2004 09:08:54 -0500

>than updating them without revving the spec.

Your generalization is cute, but wrong. Some specs get ignored, but 
NNTP is not one of them. NNTP community has been working for years on 
a revision. The fact that they haven't finished is a comment on the 
NNTP community, not on the IETF, which keeps prodding them to finish.

To the best of my knowledge, no one from your employer is 
participating, or even following the Working Group, even though you 
are a major user of the spec.

>the log from your own eye and all that...

Wrong. RFCs have errata collected in a single place. See 
<http://www.rfc-editor.org/errata.html>, which is linked from the RFC 
Editor's home page.

--Paul Hoffman, Director

---

From: Antone Roundy <[email-masked]>
Date: Tue, 9 Nov 2004 08:04:49 -0700

> will definitely work on them.
* Links: I'd love to see this nailed down a little better, but my hope 
of reaching consensus is fading, and I don't know how much more energy 
I'll feel inclined to contribute to the effort. If we're going to punt 
on making this really good, but there are any minor tweaks that we CAN 
agree on, let's at least do those.

* PaceHeadInEntry: Is there any reason not to put this in? (Note: I 
think it could use an example of an aggregated feed--the only example 
it has now is Atom over XMPP.)

* Categories: Sometimes useful. Never problematic, as far as I can 
tell. Shouldn't be too hard to nail down the specifics. Let's put it in.

* Enclosures/Images (both "favicons" and other feed- or entry-related 
images): Although one might use HTML in the content to point to some of 
these, for CaRP (which displays newsfeeds on webpages), I find it 
extremely useful to have these in a separate element--it gives the user 
much greater flexibility in formatting the output. Of course, if the 
publisher wants an image to be displayed in a particular way in 
relation to the rest of the content, then pointing to it from within 
the content is necessary, but if they simply want to specify an image 
(or whatever) to have displayed alongside the content in some way or 
another, a separate element is preferable.

* Explicit entry deletion: Another "why not put it in". Yes, once 
you've published something, it's out there, and you can't expunge it 
completely, but Arve's use-case[1] for deletion shows that there would 
be a real benefit to having a deletion mechanism (assuming it would get 
implemented, which I expect it would). This should be easy enough to 
hammer out specifics for[2]. Let's do it.

* General Extensibility: I see no reason to rush to 1.0 without nailing 
this down better. On the other hand, I personally don't care much about 
the specifics, so I also see no reason to wrangle over them for a long 
time, if that's what would have to happen to get it done.

Antone

[1] http://www.imc.org/atom-syntax/mail-archive/msg11312.html

[2] I can think of two methods--perhaps these have already been 
discussed on the list--I don't remember. One would be to add a date 
construct as a child of atom:entry to mark a deletion date. The problem 
is, of course, that you have to send a complete entry to say that it's 
not there anymore. The other is to create a child of atom:feed that 
just indicates the ID of a deleted entry. A feed might contain a 
sliding window not only on entries, but another sliding window on the 
most recent deletions.

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 9 Nov 2004 07:16:05 -0800 (PST)

This thread is offtopic so I'm changing the title 

> NNTP community, not on the IETF, which keeps

As an implementer, there is no difference between an
abandoned spec and one whose status is in limbo
because the "community has been working for years on a
revision". I find it disingenious to blame the
faceless "NNTP community" when the fact is the RFC is
an IETF spec. I wouldn't expect the W3C to blame the
"XML query community" for the lack of advancement of
XQuery. 

> are a major user of the spec.

I'm not really sure what that has to do with anything.
I don't represent Microsoft on this list (that's why
I'm not posting from my Microsoft email address) so I
don't speak for it here and even if I did this doesn't
change the fact that the NNTP spec is woefully
outdated. 

> <http://www.rfc-editor.org/errata.html>, which is

Ideally, a spec should never change after being
produced but since it is created by humans there are
bugs which oftentimes just have to be fixed. To me the
IETF approach seems very problematic compared to the
W3C approach [which also has its issues which is why I
state no one has really figured out how to solve this
yet]. 

1.) IETF approach: I go to an RFC page, read it
diligently and implement it as specified. However
there are errata which are dumped in some database on
a separate site which isn't even linked to so they are
undiscoverable. Some other implementation finds the
errata page due to its developers being savvy with the
IETF way and implements spec + errata. We can't
interop with each other and our customers & support
folks don't know why since we implement the RFC as
specced. 

2.) W3C approach: I go to a W3C recommendation page,
read it diligently and implement it as specified.
Later on there are errata which live on a separate but
linked site. Eventually the old spec is replaced by 
old spec + errata folded in. The problems with this
approach are similar to the IETF case before the
errata are folded in. Afterwards there is some
confusion when the in now turns out there are separate
revs of the spec which have the same URL and version
number/namespace name (e.g. XML 1.0 second edition,
XML Schema second edition, etc). 

Both of these approaches have their issues which I've
had to deal with as an implementer of Web
specifications. To me the W3C approach tries to strike
a good balance while the IETF approach just sounds
like a recipe for lack of interoperability. 

=====

---

From: Graham <[email-masked]>
Date: Tue, 9 Nov 2004 15:11:10 +0000

> will definitely work on them.

A quick glance through the current spec shows:
- atom:updated is currently required. I think this will lead to it 
being polluted with general "Last Modified" dates, severely limiting 
its usefulness. Seeing as it is not possible to make an element 
optional after v1.0, but it is possible to do the reverse, this one 
seems urgent.
- The discredited atom:id canonicalization nonsense still stands
- The use of terminology is very poor. For example, several elements 
define whether they can "change" or not. How can a server ever change 
something after it has been transmitted? What we mean to say is whether 
or not all instances of an entry should have the same value.
- ditto "permanent, universally unique identifier"
- No discussion on how xml:space applies to content types
- type="TEXT" does not define handling of line breaks
- No discussion on whether whitespace or parameters are allowed in @type
- Section 6 "Managing Feed State" could be a key differentiator between 
Atom and RSS if it were written rather than dropped

I'll admit to not being familiar with the process. Should the WG have 
taken a moment to fully vet their spec before asking the rest of the 
IETF to?

Graham

---

From: Robert Sayre <[email-masked]>
Date: Tue, 09 Nov 2004 10:52:54 -0500

> define whether they can "change" or not. 

I agree with this one.

> taken a moment to fully vet their spec before asking the rest of the 

Though I'm guessing I'll disagree with Graham on many of the issues he 
raised, I agree that calling it done is premature.

My issues:
PaceFieldingLinks
PaceUpdatedDefinition
Extensibility

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Tue, 09 Nov 2004 08:31:45 -0800

> PaceUpdatedDefinition

I just reviewed the answers to Paul's "consensus probe" and it seems 
clear that the revised text enjoys rough-consensus support.  I should 
let Paul say so but he's dug in at the IETF meeting this week. -Tim

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 9 Nov 2004 19:15:09 -0500

>3. You get help for aggregate feeds using atom:origin
	I have explained on numerous occasions[1] why atom:origin is useless
in the context of aggregate feeds. As far as I can see, atom:origin was
"slipped" into the spec with very little review and the alternatives to it
were never seriously and openly discussed.
	To do anything useful in the aggregate feed cases, we need to
support PaceHeadInEntry which is basically the same proposal I've been
making ever since the spring and that was discussed at the Atom Community
meeting at Sun... 
	Before you cut off debate on Atom, you should at least provide an
opportunity of review for the issues that have been lying ignored on the
table.

		bob wyman

[1] http://www.imc.org/atom-syntax/mail-archive/msg11090.html

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 9 Nov 2004 19:45:11 -0500

> Sounds like  the <source> element in RSS 2.0 
	No. The two are in no way similar. atom:origin has no relationship
to <source/>, at least as <source/> is defined in the RSS V2.0
specification. Atom:origin can only be used to "identify" a source while an
RSS V2.0 <source/> can be used to locate a source. These are very different.
	atom:origin is a character-by-character copy of an atom:id which is
a URI that can't be reliably dereferenced. An atom:origin might look like:

<origin>tag:blogger.com,1999:blog-555</origin>

	RSS's <source/> element[1] provides a copy of the title of the
source feed and has a required attribute which is the URL of the source.
(i.e. a URI which can be dereferenced.) An RSS <source/> might look like:

<source url="http://static.userland.com/tomalak/links2.xml">Tomalak's
Realm</source>

	As I've explained before, atom:origin is largely useless in
aggregated feeds.[2] On the other hand, RSS's <source/> element is useful
since it communicates the most important information that an aggregator
needs to know about an entry's source feed when it displays that entry. The
PaceHeadInEntry defines a mechanism which should be combined with an
atom:source, similar to that defined by RSS V2.0, in order to properly
support the embedding of entries in aggregated feeds.

		bob wyman

[1] http://blogs.law.harvard.edu/tech/rss#ltsourcegtSubelementOfLtitemgt
[2] http://www.imc.org/atom-syntax/mail-archive/msg11090.html

---

From: Eric Scheid <[email-masked]>
Date: Wed, 10 Nov 2004 14:15:29 +1100

> <origin>tag:blogger.com,1999:blog-555</origin>

any screaming objections to this...

    <origin href="...">tag:blogger.com,1999:blog-555</origin>

or even possibly this:

    <origin href="..." type="application/rdf+xml" title="My RDF Feed"/>

Hmm ... someone remind me why atom:origin wants to communicate the feed:id
and not the feed:href? Remembering though that every entry will have an
atom:id to clearly identify the entry. Is it so we can establish precedence
and history of that entry being passed from aggregator to aggregator?

If an entry is originally published in Feed-A, picked up by an aggregator
and republished in Feed-B, which is then picked up by another aggregator and
republished in Feed-C ... what should the value of atom:origin in Feed-C be?
Should it be the atom:id of Feed-B, or Feed-A?

I'm starting to see <origin> as just a special case of <link>, the same way
the various service point links are. If so, then maybe it shouldn't be a
special case of <link> at all, since it will have a retrievable href which a
user might want to go explore (thus fitting the pattern of other <link>
elements according to whichever pace).

e.

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 10 Nov 2004 03:58:21 +0000

> support the embedding of entries in aggregated feeds.

I would like to see PaceHeadInEntry on the next work queue.

Fwiw, I came up with atom:origin. It was designed very deliberately 
to stir the pot around

  1) aggregated feeds,
  2) relationships between feeds and entries,
  3) Atom's identity model.

I don't know whether references or values are the way to go, but I 
know we can do better; and the other feed formats are in no great 
shape either.

In the meantime we have a lot to get through on this work queue and 
I'm not prepared to add another thread onto the recent list activity 
(Bray has been stirring a pot of his own). I request that we put 
this one aside for now.

cheers
Bill

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 9 Nov 2004 23:52:31 -0500

><origin href="..." type="application/rdf+xml" title="My RDF Feed"/>
	That's more expressive than RSS V2.0's <source/> since it provides
type as well as URL and title, however, it still doesn't provide feed-level
metadata such as "author", "copyright", etc. that are potentially vital to
the proper interpretation of an entry. Some feed-level metadata is
inheritable by entries, other feed-level metadata is important for
understanding the context in which the entry was published or within which
it was intended to be interpreted.

> If an entry is originally published in Feed-A, picked up by an
> aggregator and republished in Feed-B, which is then picked up by
> another aggregator and republished in Feed-C ... what should the value
> of atom:origin in Feed-C be? Should it be the atom:id of Feed-B, 
> or Feed-A?
	I believe that an entry can only have one "origin". In the case
above, clearly the "origin" is Feed-A. It might, for some applications, be
interesting to note from where the entry was most recently copied, however,
that would be something other than origin. 

		bob wyman

---

From: Eric Scheid <[email-masked]>
Date: Wed, 10 Nov 2004 16:00:45 +1100

On 10/11/04 3:52 PM, "Bob Wyman" <[email-masked]> wrote:

> the proper interpretation of an entry.

ah, but now you do have the @href, so it won't be hard to go fetch it

except ... besides the roundtrip pain you might encounter the current feed
with changed meta-data (eg. a guest author), different from when the entry
was actually published. Life would be so much simpler with a SSFF with
discrete <entry> documents ;-)

> Some feed-level metadata is

just how far do we push the need for context though?

> that would be something other than origin.

so an (unwritten?) rule of atom:origin is that when aggregating entries from
source feeds, if the entry already has an atom:origin don't replace it with
a new one?

e.

---

From: "Bob Wyman" <[email-masked]>
Date: Wed, 10 Nov 2004 01:37:13 -0500

>ah, but now you do have the @href, so it won't be hard to go fetch it
	Actually, it would be quite a burden. You would have to fetch the
full source feed for every entry in the aggregated feed just to pick up a
few header elements. Given that many feeds contain 20, 30, or more items,
and it isn't possible to fetch less than 100% of a feed given HTTP, you're
going to be wasting more than 10 times as much network bandwidth then would
be used if the <head/> elements were simply inserted into the entries.
	Some will argue that you could "cache" header data you've seen for
various "origin" feeds. However, if the entries inserted into the feed come
from a large pool of feeds (like the millions that we filter at PubSub),
then you're going to find that the vast majority of entries in the feed will
be appearing for the first time or will appear so infrequently that cached
data will have expired. Thus, the solution you propose, fetch the feed to
pull in the contents of <head/>, turns the system into nothing more than a
poorly and inefficiently built ping based system. i.e. the contents of the
aggregated feed really should be reduced to nothing more than an atom:id and
the origin URL. Since you're going to fetch the feed anyway, why bother
having any more data in the aggregate feed?
	I still contend that atom:origin does nothing useful for aggregated
feeds. Origin, even if extended as you propose, just doesn't address the
issues in a reasonable fashion.

		bob wyman

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 11 Nov 2004 04:22:16 +0100

> feeling that many good ideas and features got kicked out because there  

That's my impression as well. There's definately some disagreement within  
the WG regarding what Atom should be. Someone seems to think it should  
only be a better specified RSS 2.0 while someone actually wants to break  
some new ground and have the format bring something fresh (but useful) to  
the world of syndication.

If the only reason we can whip at implementors for deploying Atom is «It's  
standardized. It has its very own RFC number and all!», I don't think  
everyone will do it as quick as we would hope.

> and its many brothers and sisters. But, as Dare states it, there is no  

Exactly.

> answering these questions, but beside the charter there is a emotional  

I agree.

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

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 11 Nov 2004 19:28:20 -0800 (PST)

--- Tim Bray <[email-masked]> wrote:
> covering the missing pieces?  

I'm saying that at present the Atom adds fragmentation
to the world of XML syndication for little or no
benefit. Starting a brand war with RSS may be good for
certain egos but it is bad for end users. As someone
who's been having to explain this mess to people at
Microsoft and figure out how to make this stuff more
mainstream, further fragmentation with little
differentiation between the choices is not a good
thing. 

On the other hand, there isn't much I want from an XML
syndication format that can't be done with one of the
existing flavors of RSS (1.0 or 2.0) and extensions.
So I won't waste your time listing the features I'd
like to see in a syndication format. 

=====

---

From: Robert Sayre <[email-masked]>
Date: Thu, 11 Nov 2004 23:09:01 -0500

Dare Obasanjo wrote:

> certain egos but it is bad for end users.

Standardization as "brand war". Interesting. I don't think anyone will 
be surprised if Microsoft tries to squash an IETF spec in favor of some 
ad-hoc thing they can control.

Robert Sayre

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 11 Nov 2004 21:30:20 -0800 (PST)

> ad-hoc thing they can control.

Nobody at Microsoft cares about your petty little ego
struggles with Dave Winer. If I wasn't working on RSS
Bandit then I'd be just like the rest of the folks
interested in XML syndication at Microsoft and ignore
Atom. 

PS: Like I've said before, I don't represent Microsoft
on the list so you can cut the innuendo. 

=====

---

From: "Bob Wyman" <[email-masked]>
Date: Fri, 12 Nov 2004 00:30:14 -0500

Robert Sayre wrote:
> Standardization as "brand war". Interesting. I don't think anyone
> will be surprised if Microsoft tries to squash an IETF spec in
> favor of some ad-hoc thing they can control.
	I don't believe that it is appropriate to trash Microsoft, or any
other vendor, in this fashion in this forum. It does not contribute to our
goal of having a reasoned discussion of the issues.

	As far as Dare's arguments go, he says: "I'm saying that at present
the Atom adds fragmentation to the world of XML syndication for little or no
benefit." Well, I can assure you that I do see great benefit from Atom over
RSS today. Our experience is that Atom feeds are much cleaner, easier to
parse, and much more consistent in encoding from site to site than RSS feeds
are. Reading RSS feeds is more of an art than a science. There are so many
flavors of RSS that it's hard to claim that the code you need to read RSS is
a "parser" -- it is more like a heuristic hint processor. i.e. A fancy
guessing machine... 

		bob wyman

---

From: Robert Sayre <[email-masked]>
Date: Fri, 12 Nov 2004 00:47:44 -0500

Dare Obasanjo wrote:

> struggles with Dave Winer. 

Ah, yes. Everyone who disagrees with Dare or has a problem with RSS is 
engaged in a "petty little ego struggle."

> If I wasn't working on RSS

We should be so lucky!

> on the list so you can cut the innuendo. 

Yet you keep bringing up Microsoft *and* Dave Winer. I think you're 
leading the list in mentions of Dave Winer and Microsoft.

Robert Sayre

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 11 Nov 2004 21:45:21 -0800 (PST)

> a "parser" -- it is more like a heuristic hint

If Atom was going to be the first or even the second
XML syndication format on the block I'd probably share
your sentiments. However as for your statements that
Atom feeds are in general of higher quality than RSS
feeds, I'll direct you to an excerpt from a post made
by Bjarne Stroustrup a few years ago[0].

"When C++ was new, one of the things that pleased me
most was that discussions about C++ were so much
better informed than discussions about most other
languages, that the understanding of key concepts were
so much better in C++ groups than in, say, C and
Pascal groups, and that groups such as comp.lang.c++
were so much more polite and supportive than that of
other groups. 
Clearly, I thought naively, C++ attracts a much better
class of programmers, learning C++ helps people to
absorb the key concepts of good programming/design,
and the resulting success makes people more tolerant
and helpful. 

I was wrong. The phenomenon was real, but it had
little to do with C++. In a small dedicated community,
life is relatively easy. people do their homework,
people have access to reasonable sources of
information, gross errors and misconceptions are
corrected before they can cause significant harm,
compilers and teaching materials are up-to-date, etc. 

This is not and cannot be the case in a
multi-hundred-thousand member community: Some will be
taught out of outdated or unsuitable books, some will
use antiquated compilers and tools, some will be
taught by charlatans, some will be remote from current
and reliable news-sources, some will have unsuitable
rules and regulations imposed on their work, etc.
Also, in a rapidly growing community, most users will
be novices." 

RSS feeds are basically mainstream and are being
generated by orders of magnitude more people than are
generating Atom feeds many of whom aren't XML
syndication geeks. This accounts more for the issues
with quality of the feeds than the whether the
incomplete and ambiguously defined Atom 0.3 spec is of
any higher quality than the RSS 0.91, 1.0 or 2.0
specs. 

[0] http://www.research.att.com/~bs/blast.html 

=====

---

From: Robert Sayre <[email-masked]>
Date: Fri, 12 Nov 2004 00:51:28 -0500

Dare Obasanjo wrote:

> 
> RSS feeds are basically mainstream

But I thought you were working to make it mainstream? Which is it?

>  and are being

A plausible theory, but you have no way of substantiating it. You're 
posting on a mailing list full of people who want Atom to exist for a 
variety of reasons. I'm not sure why you think you're going to convince 
them otherwise. You're just wasting our time with this trash. Over and 
over and over again.

Robert Sayre

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 11 Nov 2004 21:56:07 -0800 (PST)

--- Robert Sayre <[email-masked]> wrote:
> them otherwise. 

I'm not trying to convincing anyone of anything. Come
to think of it I'm not even sure why I'm still
bothering to read or post to this list. 

*unsubscribed*

=====

---

From: "Bob Wyman" <[email-masked]>
Date: Fri, 12 Nov 2004 01:04:13 -0500

>*unsubscribed*

Neither that nor the provocation that lead to it was useful.

Dare's participation may have been exasperating at times, nonetheless, it
was useful. We've lost something here... This WG is diminished by this loss.

		bob wyman

---

From: Martin Duerst <[email-masked]>
Date: Fri, 12 Nov 2004 15:48:18 +0900

>was useful. We've lost something here... This WG is diminished by this loss.

+1.               Regrads,   Martin.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 11 Nov 2004 23:32:17 -0800

I think it is important to keep in mind that IETF working groups,
unlike typical discussion mailing lists, have a given set of tasks
to accomplish as a collaborative work.  Collaboration requires that
those involved be working towards a common goal, even if there is
disagreement on how best to get there.  Folks who disagree with
the goal itself should argue outside the working group, not within.

I see no reason to tolerate harbingers of doom unless they are
being constructive. If there is a hole, plug it. If there is a
missing feature, describe it. If there is a bug, squash it.
Collaboration isn't hard once people agree to be constructive.

....Roy

---

From: Danny Ayers <[email-masked]>
Date: Fri, 12 Nov 2004 12:04:44 +0100

On Fri, 12 Nov 2004 01:04:13 -0500, Bob Wyman <[email-masked]> wrote:
> was useful. We've lost something here... 

A challenge, perhaps?

Quoting Dare from earlier in the thread:
[[
]]

That is exactly what I found exasperating, that his sights were set on
what could be done already, not what could be fixed or *improved* over
1.0 and 2.0. People like Dare, Don Park and others are unlikely to see
much benefit as long the group aims merely for
lowest-common-denominator RSS 2.0, patched and rebranded.

Ok, I think it would take considerably more than a months of Sundays
to say, persuade Dare of the benefits of the RDF model or whatever, he
has a strong naysaying streak. But if at the end of the day this WG
doesn't come up with a deliverable that Dare could confidently take to
MS and say "this is much better" then we've missed something.

Cheers,
Danny. 

-- 

http://dannyayers.com

---

From: Henry Story <[email-masked]>
Date: Fri, 12 Nov 2004 13:48:53 +0100

I think it is a pity that Dare should be unsubscribing just now. My 
feeling is that
we are just about to reach a historic resolution point in the debate 
between the various formats that will bring together the best of all 
the flavours of RSS. We are really close to having something that will 
be greater than all of the previous efforts combined. The beauty is 
that we are about to show that all sides were correct:

	- Dare was right in emphasizing namespaces
	- RDF people were right in emphasizing the combinatorial power of RDF
	- Tim Bray, and other xml purist, are correct in emphasizing simplicity

If we can show how Atom can be extended into RDF-XML, without being by 
default RDF-XML, in such a way that a simple xml parser with no 
knowledge of RDF can read default RDF extensions correctly, then we 
will be on our way to explaining some of the power of the semantic web, 
but also in helping the semantic web folk perhaps come up with a better 
version of RDF-XML - call it RDF-XML-2 - such that Atom, as it 
currently stands really is RDF-XML-2.

	It may be weird, but I think everyone here has been looking at 
different parts of a huge elephant, and we are just about to see the 
elephant.

All it requires is a little compromise, a little flexibility of mind, a 
little openness to the new, and we will have something that is truly 
great. The RSS wars will seem funny when looked at it from the other 
side.

	Henry Story

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 13 Nov 2004 02:08:22 +0100

> Particularly when the Protocol draft seriously needs work and progress.

I agree that the world should use Atom sooner than later, but think we  
should bake a few more things into the format specification before we say  
it's finished. Plus, the specification is in urgent lack of examples, a  
couple of missing chapters, etc.

What if we try to set a tentative «goal date» for the format? Then we  
freeze it, work out all the details in the text so the freezed text gets  
polished and perfect, and then we move on to the protocol one hundred  
percent?