Subject: Shipping Atom products prematurely

From: Mark Nottingham <[email-masked]>
Date: Sun, 15 Aug 2004 15:21:00 -0700

I've just changed the old, pre-WG drafts that I host on mnot.net to 
clearly state that they're not to be implemented, and are superseded by 
the work here.

One of the things that drove me to do this is the increasing incidence 
of vendors shipping products and services that "support" Atom, even 
though it's clearly marked as a pre-draft (on my site) and only for 
experimental implementation (in the WG's drafts).

Working on experimental Atom implementations is great because it helps 
us get experience and find problems. However, shipping it in 
mass-market products before it's done is likely to lead to a lot of 
interoperability problems, end-user support issues and even barriers to 
adoption as the spec matures.

As such, I think the WG should proactively contact vendors of consumer 
products and services and ask them to refrain from integrating Atom 
support until it's done. They have the best of intentions by supporting 
Atom, but may do more harm than good by accelerating the adoption of it 
prematurely.

I'm not naming names here, but I have two vendors in particular in 
mind. I *don't* mean the smaller aggregator-only vendors or personal 
blogs who have made a choice to experimentally support Atom; I mean 
those that are pushing Atom to an audience who doesn't understand what 
the issues are.

Thoughts?

--
Mark Nottingham     http://www.mnot.net/

---

From: "Bill Kearney" <[email-masked]>
Date: Sun, 15 Aug 2004 19:16:15 -0400

> those that are pushing Atom to an audience who doesn't understand what

Yes, from a syndication format I've found it HIGHLY premature for use of Atom.
It's a great thing and when it's offered in parallel with mature standards like
RSS-1.0 it's a great thing.  But to offer it as the SOLE syndication format /at
this time/ is a less-than-idea situation.  This implies nothing about any one
format being any better or worse than another.

Now, if the choice is 'atom or nothing' then I'm certainly willing to support
use of it.  I'd rightly complain about the surge of naive developers we'll have
to put up with as legacy nightmares because of it.  This, however, is
considerably less worse than putting up with feeding that nitwit ego sure to
crow about RSS...

I'm not sure how I'd feel about it from a client/server editing perspective.
There are some disjoint issues between what the hosting environments "need" and
what some folks are insisting upon grafting into atom.  This is, perhaps, a much
stickier issue but one that might easily be resolved by establishing compliance
profiles with perhaps some timeframe expectations.

-Bill Kearney
Syndic8.com

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 16 Aug 2004 01:25:34 +0100

> Thoughts?

I mostly agree. Tho' in one way, stopping people shipping - well as 
problems go there's worse. Also,

a) we should start setting expectations as to when this thing will 
ship. I have people asking me and the answer I give is I don't know, 
but I know I'm not confident about 2004.

b) the chairs (and maybe the editors) need to continue to be 
aggressive about controlling discussion on this forum. Yes of 
course, consensus good, two legs bad, but if Hoffman or Bray say to 
stfu, please continue to do it.

c) churn the specs more frequently. Currently we have a July 15 
draft that expires next January (that's too many dog years imho) And 
personally I'd rather be tracking spec text than wiki pages at this 
stage.

d) the [[ ]] style callouts need to be laced with !!!, ###, @@@ or 
??? marks - that looks more hacked up, unfinished and dangerous to 
the eye. It's a little thing, but you guys are far too neat.

Observation: I'm currently finding the optimal contribution I can 
make is to not post as much.

cheers
Bill

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 15 Aug 2004 19:19:41 -0700 (PDT)

> experimental implementation (in the WG's drafts).

I know what you mean. I pinged a contact of one of the
vendors whose support of Atom was all over the news of
what they plan to do when Atom becomes final since I'm
worried about what could happen to the thousands of
RSS Bandit users that could be shafted if they switch
Atom versions. The response I got was basically
'Marketing will figure it out', I would have pressed
the point but Sam [Ruby] was on the email thread and
he claimed that such a discussion wasn't fruitful or
something similar so I let it go. 

> Atom, but may do more harm than good by accelerating

I'm not sure what you expect to happen here. For those
that have already deployed draft verions of Atom the
horse has already left the barn. The best the WG can
do is find out what they plan to do in future when
newer drafts show up or the specs become final. 

For those that haven't deployed the drafts unless you
have access to the precrime unit from Minority Report
there isn't anyway to contact them and tell them not
to do it. :) 

> those that are pushing Atom to an audience who

Never ascribe to malice that which can be explained by
incompetence[0]

[0]
http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=49b611e5-3788-4921-8b55-00fc08de7e9e 

=====
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!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 15 Aug 2004 20:02:05 -0700

> newer drafts show up or the specs become final.

I'm specifically thinking of very large vendors who have announced 
support for Atom in upcoming products and IIRC have seeded developer 
betas, and those who have made Atom feeds the preferred method of 
syndication for large-scale Blog hosting betas.

Remember that the deployment footprint of Atom is still relatively 
small, especially on the consumer side; if we don't check this, it will 
be very large, and people will start arguing "we can't change feature X 
in the draft because vendor Y has already shipped n million units that 
depend upon it."

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 16 Aug 2004 08:07:49 -0700 (PDT)

> in the draft because vendor Y has already shipped n

I understand that but what do you want them to do?
Stop deploying the Atom syndication format and Atom
API and revert to RSS & Blogger API/MetaWeblog
API/etc? Freeze deployment of Atom at whatever drafts
they are currently using then upgrade when v1.0 ships?
Or something else. 

Simply telling them "I don't like that you are doing"
without providing an alternative is one way to ensure
that your opinion is ignored. What is the alternative
that you think the WG should suggest to these vendors?

=====

__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 16 Aug 2004 08:22:06 -0700

Ah; I misunderstood your question. My suggestion would be to not ship 
Atom in mass-market products until it's done (or at least close to 
being done). RSS is already out there.

Of course, this stance puts enormous pressure on the WG to get done 
quickly, but I have no problem with that...

On Aug 16, 2004, at 8:07 AM, Dare Obasanjo wrote:
> 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.
>
>
>

---

From: Antone Roundy <[email-masked]>
Date: Mon, 16 Aug 2004 09:51:33 -0600

> being done). RSS is already out there.
I would think that we'd like to recommend not shipping Atom in 
mass-market PUBLISHING tools till it's done, but off the top of my 
head, I don't see any problem with shipping it in CONSUMING tools.  Am 
I missing something?

---

From: Walter Underwood <[email-masked]>
Date: Mon, 16 Aug 2004 09:19:11 -0700

--On Monday, August 16, 2004 8:07 AM -0700 Dare Obasanjo <[email-masked]> wrote:
> API/etc?

Use time-limited beta releases. If the product implements
a draft Atom spec, then it is a beta. The product should
time out when the draft does, or earlier. The click wrap
and release notes should make it clear that the Atom
implementation is experimental.

There is no practical way to support an implementation of
a protocol draft. The protocol spec may change in incompatible
ways, where it is really difficult to distinguish between
the two. Without support, how can it be a product? As a
commercial product, you could get in trouble with your
accountants for recognizing support revenue for something
you can't support. Yes, post-bubble accountants pay
attention to that.

And please just name companies instead of saying "an unnamed
large vendor". If they've made a public statement, there is
nothing to gain by being obscure.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 17 Aug 2004 00:59:09 +0200

On Mon, 16 Aug 2004 09:51:33 -0600, Antone Roundy <[email-masked]>  
wrote:

> mass-market PUBLISHING tools till it's done, but off the top of my head,  
> I don't see any problem with shipping it in CONSUMING tools.

+0.5. I can't see any major problems with allowing consumer tools to have  
flaky Atom support; it's almost always the producers that are the problem.  
Unless the producers generate Atom documents to fit buggy clients, that  
is. That could happen too.

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

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 16 Aug 2004 21:49:15 -0400

Mark Nottingham wrote:
> I think the WG should proactively contact vendors of consumer
> products and services and ask them to refrain from integrating
> Atom support until it's done.
	I don't get it. Just a few months ago, the fact that
LiveJournal, Blogger, and Typepad supported Atom 0.3 was proclaimed to
be a wonderful thing. Now, some seem to be saying that it is bad if
others do what was once considered good. How can this make sense?
	When you speak of "Atom" what is it that you are referring to?
Is it the Atom 0.3 that people were once encouraged to support or is it
the Atom format that is being defined in ID's today? I can understand if
you say that people shouldn't ship support for Atom as defined in the
IETF ID's, however, how can you object to people implementing what
LiveJournal, Blogger, Typepad, and many others have implemented and been
acclaimed for implementing?
	I realize that it will be messy getting people to move from Atom
0.3 to Atom 1.0. However, this is no more messy then getting them to
move from any of the many flavors of RSS.

		bob wyman

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 16 Aug 2004 20:09:41 -0700

> others do what was once considered good. How can this make sense?

Please re-read what I wrote. If people go out of their way to get an 
Atom client, or to consume an Atom feed, that's fine. It's not fine if 
products or services put Atom into the hands of people who aren't aware 
of what it or syndication is before we're done.

LiveJournal, Blogger and Typepad were/are relatively small services 
that have a fairly technically savvy customer base, compared to the 
unwashed masses. Personally, I was somewhat uncomfortable with early 
adoption like this, but it was a limited deployment and didn't have too 
many bad effects.

However, people are starting to talk about building Atom into operating 
systems, browsers, and other non-specialist software, and that will 
have a lot of effects that will be very difficult to manage.

Note that there's a difference between announcing intended support for 
Atom -- which is wonderful -- and shipping products that depend on an 
unfinished spec.

> the Atom format that is being defined in ID's today?

Both.

> move from any of the many flavors of RSS.

We can and should do better than that.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 17 Aug 2004 13:24:24 +1000

> is. That could happen too.

There is a third category too -- mass-market publishing tools which are NOT
SHIPPED, but are instead a centralised service. Like Blogger. They have
complete control over their software, and can roll out an update which
affects ALL their users at once. This is different as from a user-installed
product for which there will always be old versions lingering around.

I don't see any major problems with a centralised service rolling out
more-stable-than-not versions of Atom. They shouldn't roll out do-not-deploy
versions except as an undocumented *extra*, one which could disappear at any
time.

e.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 16 Aug 2004 20:39:37 -0700

> head, I don't see any problem with shipping it in CONSUMING tools.  Am 

Vendor A ships 10 million units of their software that includes support 
for reading Atom feeds. Now, every time we suggest that something 
change in the spec, we run up against the "but it's already on 10 
million desktops" argument.

This is especially worrisome, considering that we haven't yet made 
versioning and extensibility bulletproof.

I don't want this to be a huge issue; however, the expectations need to 
be managed.

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 16 Aug 2004 20:52:33 -0700 (PDT)

> > others do what was once considered good. How can

I dislike generic statements like these. Whoever said
it was great that Google was adopting the Atom 0.3
syndication format it wasn't me. For all I know, the
same people who said it was great then still think it
is now. I thought it was a bad idea then and I still
think it was a dumb thing to do now. 

> adoption like this, but it was a limited deployment

I wouldn't call services that have over a million
active users (Blogger and LiveJournal) as small
services  nor would I claim that they have a fairly
technically savvy audience. I suspect you are
confusing the multitude of MovableType users who are
Perl savvy and pipe up in RSS discussions with the
average teenage girl or college freshman who's
publishing their diary on Blogger.
 
> have a lot of effects that will be very difficult to

Interesting. Which operating systems and browsers have
announced Atom support? 

> Atom -- which is wonderful -- and shipping products

Agreed.

=====

---

From: Dan Brickley <[email-masked]>
Date: Tue, 17 Aug 2004 06:10:33 -0400

* Mark Nottingham <[email-masked]> [2004-08-16 20:39-0700]
> versioning and extensibility bulletproof.

+1, please let's not have to leave extensibility and versioning for v2.0
because of this.

> I don't want this to be a huge issue; however, the expectations need to 

Yup. For sites *producing* Atom feeds, perhaps encourage a bit of
boilerplate at the top of the file in XML comments, perhaps something
like:

<!--  Early Adoption Warning
This document uses an in-progress draft of the Atom publishing
format. Atom is undergoing active development and standardization 
within the IETF, see http://www.ietf.org/html.charters/atompub-charter.html
Please note that the AtomPub WG will not allow deployment of early 
implementation of draft proposals to hinder improvements to the Atom
design. Implementor feedback is welcomed by the WG, however implementors 
should be cautious when deploying prototype Atom software to end-users. -->

...or words along those lines? Less wordy might be wise, for big sites
with lots of feeds... (eg. a pointer to text elsewhere perhaps)

cheers,

Dan

---

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

--- Dan Brickley <[email-masked]> wrote:
> within the IETF, see
http://www.ietf.org/html.charters/atompub-charter.html
> software to end-users. -->

This boiler plate is meaningless. Why would a regular
aggregator user see it or even care? 

Once Google made Atom 0.3 the only format supported by
certain Blogger sites aggregator authors were
pressured to implement a interim version of the draft
spec. There are now literally thousands of desktop
aggregators that support Atom 0.3 on users desktops.
I've counted aboyut 50,000 downloads of RSS Bandit
versions wioth Atom 0.3 support. Both FeedDemon and
SharpReader are more popular so it isn't inconceivable
for there to be 100,000 - 200,000 users out there who
are dependent on major sityes providing Atom 0.3
feeds. This number is growing by tens of thousands of
users a month. 

What the heck is going to happen once Atom 1.0 comes
out. Will all these users be out of luck or will
Google/Blogger continue supporting Atom 0.3
indefinitely? What happens when even more sites follow
Google's lead? 

Finally, how the does putting some comments in an XML
file actually help this problem? 

=====

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

---

From: Robert Sayre <[email-masked]>
Date: Tue, 17 Aug 2004 11:27:30 -0400

> indefinitely? What happens when even more sites follow

How about they deploy the Atom 1.0 feeds at new URIs, and permanently 
redirect the Atom 0.3 feeds after a reasonable period of time.

I got sick of maintaining RSS feeds on my own site, so I stuck permanent 
redirects from the old RSS URIs to the Atom feed. Seemed to work just 
fine. After a month or so, I rarely got requests for the RSS files.

 > in the draft because vendor Y has already shipped n million units that

While I share your concern, I think it's too late. The best-of-breed 
clients already support Atom 0.3. I think Radio is the only major client 
that doesn't. It's a capability that consumers expect, and competitors 
will point out "lack of Atom support" if an aggregator doesn't support 0.3.

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Tue, 17 Aug 2004 09:40:52 -0600

> indefinitely? What happens when even more sites follow
If "Google [makes] Atom [1.0] the only format supported by certain 
Blogger sites aggregator authors [will be] pressured to implement ... 
version [1.0] of the ... spec."  Those users won't be any more out of 
luck than they were when Google moved from RSS to Atom 0.3.  They'll 
have to wait however long it takes till aggregator authors implement 
Atom 1.0 support, and then upgrade their aggregator.

Google could, of course, continue to support 0.3 for a while, perhaps 
enabling each blog to have 2 versions of the feed.  After a few months, 
or however long seems appropriate, they could drop 0.3 support.  
Anybody who hadn't bothered setting up a 1.0 feed but did have an 0.3 
feed could suddenly find it changed to 1.0.  Anybody who had both would 
end up with just the one.

Antone

P.S. No need to CC me on messages on this thread...or any other thread 
for that matter.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 17 Aug 2004 08:46:17 -0700

> aggregator user see it or even care?

I tend to agree.

I was hoping that this group could come to an easy consensus about this 
(after all, it's pretty clear in the I-Ds), work with the vendors 
present to make sure that any products or services are appropriate, and 
reach out to vendors who aren't participating in this group to do the 
same.

The high points, in my mind, would be:
   - do not ship Atom support in "final" products; use clearly marked 
vehicles like "alpha" "beta" or "experimental."
   - likewise, clearly mark use of "Atom" in links, marketing and other 
documentation as "experimental"
   - support mature alternatives (e.g., RSS) at least until Atom is final
   - have an acceptable transition plan that forces upgrade (e.g., 
time-expired betas, removing old feeds)

The last one is especially important, because many larger, mass-market 
products and services will be reluctant to "break" people who are 
depending on the previous behaviour. If they're not willing to do that, 
they shouldn't be using Atom right now.

---

From: Walter Underwood <[email-masked]>
Date: Tue, 17 Aug 2004 08:54:22 -0700

> +1, please let's not have to leave extensibility and versioning for v2.0

This can be handled by something much simpler than protocol
versioning. For example, the protocol drafts can specify the
root element as <atom-draft>, then change it when published.

wunder

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 17 Aug 2004 17:45:35 +0100

Dare Obasanjo wrote:

> certain Blogger 
> [...]

So many questions.

What do you suggest should be done, if anything?

cheers
Bill

---

From: [email-masked]
Date: Tue, 17 Aug 2004 13:15:27 -0400

Agreed.

> aggregators that support Atom 0.3 on users desktops.

I wasn't a big fan of Google's decision either, as like you said, it essentially
forced aggregator authors to implement a spec that was not yet finalized. And
once more aggregators started supporting it, more sites in turn have started
publishing Atom 0.3 feeds. This has gotten us to a point where when a new
version of Atom is published, there will still remain many published feeds out
there that still use the old (incompatible) spec., meaning
aggregators will need to continue to support these out-of-date Atom specs.

There is a certain individual who shall remain nameless who loves to blog about
the many incompatibilities between RSS versions. The widespread current
adoption of Atom 0.3 pretty much guarantees it will end up the same way. It may
even be worse because while new versions of RSS have given SOME thought to
backward compatibility (even if that compatibility wasn't perfect), Atom won't
as the previous spec was not final anyway.

> indefinitely? What happens when even more sites follow

The users will be fine. Aggregator authors will just be forced to implement
Atom 1.0. Unfortunately, as stated above, Atom 0.3 (and 0.4, 0.5 or any other
intermediate versions there may be) will still need to be supported as well.

> file actually help this problem?

It won't. Aggregator authors should already be well aware of this stuff. It's
feed publishers that should be reminded somehow to upgrade to the latest Atom
spec when this is released. While this issue could theoretically be forced if
all aggregator authors were to agree to stop supporting Atom 0.3, I seriously
doubt this will happen. It's a prisoner's dilemma - if we all agree to do it,
we'd all be better off eventually. If a few continue to support 0.3 though,
they'd have an edge which would allow them more users at the expense of the
conforming aggregators, which would force those to reactivate 0.3 support. This
in turn means there will be little incentive for anyone to upgrade their then
outdated 0.3 feed to the latest release.

I'd welcome any suggestions on how to solve this problem - quite frankly, I'm
not sure there is a solution though... unless there's some legal mumbo jumbo
that could be put in the final spec that required any product that uses the
Atom 1.0 spec stop supporting any previous versions (beyond that which come
automatically due to backwards compatibility of course) after a certain date.
I'm no lawyer so I have no idea if this would be possible, but even if it is,
the open nature of Atom doesn't seem to mix too well with these kinds of
restrictions...

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 17 Aug 2004 11:17:53 -0700

At 1:15 PM -0400 8/17/04, [email-masked] wrote:
>Aggregator authors will just be forced to implement

That's not at all clear.

So far, we have only seen the pre-IETF version 0.3 in the wild. I 
have heard of zero reports of implementations of the -00 or -01 
drafts that have been seen in feeds. This is a Very Good Thing. FWIW, 
the 0.3 version doesn't even exist as an IETF Internet Draft.

Any vendor who implements from anything other than the final IETF 
standard will have a host of problems interoperating in the future. 
IETF documents expire after six months, and are usually unavailable 
within nine months. So, if someone releases code based on 
draft-ietf-atompub-format-07.txt, that document will soon become 
unavailable, meaning that someone else cannot determine how to 
interop with it in the future.

Of course, the RFCs we produce will live forever. You can still find 
RFC 1 on IMP software at <ftp://ftp.rfc-editor.org/in-notes/rfc1.txt> 
35 years later.

The Atompub WG *will* have proper and understandable versioning in 
both the format and protocol before we are finished.

Until the final, standardized version, the documents will make it 
clear that implementers should only implement for internal use. If we 
find some implementers creating feeds from pre-standards IETF drafts, 
a bit of quick public education can probably fix the problem.

--Paul Hoffman, Director
--Internet Mail Consortium

---

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

> intermediate versions there may be) will still need

The implicit assumption is that tens of thousands to
hundreds of thousands of users will be forced to
upgrade. This doesn't seem like a good option to me
since it leads to a negative user experience but it
doesn't seem like we have any choice. I still remember
all the negative feedback when Mark Pilgrim switched
his blog to providing Atom-only feeds. :(

=====

__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail

---

From: Mark Pilgrim <[email-masked]>
Date: Tue, 17 Aug 2004 14:38:12 -0400

> his blog to providing Atom-only feeds. :(

I must have missed the part where I was put under any obligation
towards you whatsoever.

-- 
Cheers,
-Mark

---

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

> I must have missed the part where I was put under

The point is that forcing users to upgrade their
aggregator to read a feed they could read just fine a
day before results in pissed off users and I provided
a real-world example.

I'm not sure where a claim that Mark Pilgrim is
obligated to Dare Obasanjo arises from the above
statement. 

=====

---

From: [email-masked]
Date: Tue, 17 Aug 2004 14:46:27 -0400

> the 0.3 version doesn't even exist as an IETF Internet Draft.

I've seen a few Atom 0.2 feeds in the wild, but agree that these are very sparse
and therefore not much of a problem. Atom started getting much more popular
with 0.3 though, so I expect this to become a bigger problem when the next
version is published.

> a bit of quick public education can probably fix the problem.

hmm... seems to me that "a bit of quick public education" might be overdue
here... quite a few Atom 0.3 implementations out there that aren't internal...

---

From: [email-masked]
Date: Tue, 17 Aug 2004 14:57:37 -0400

> his blog to providing Atom-only feeds. :(

I can see only two alternatives to this:
1) make all subsequent versions of Atom backwards compatible with Atom 0.3 (I
think most here would agree this would be a bad idea)
2) put a recommendation in any pre-1.0 atom spec stating that, while
experimenting is allowed (or even encouraged), authors should also publish a
feed using a more mature and stable format (i.e. one of the RSS dialects) for
use by aggregators that do no support this particular pre-1.0 Atom version yet
(or not anymore, once a new version is published).

---

From: Graham <[email-masked]>
Date: Tue, 17 Aug 2004 14:12:56 -0500

On 15 Aug 2004, at 5:21 pm, Mark Nottingham wrote:

> support until it's done. They have the best of intentions by 
> supporting Atom, but may do more harm than good by accelerating the 
> adoption of it prematurely.

Isn't the first step getting atomenabled.org taken off air?

Graham

---

From: James Robertson <[email-masked]>
Date: Tue, 17 Aug 2004 15:16:46 -0400

>think most here would agree this would be a bad idea)

That would be bad how, exactly?

>(or not anymore, once a new version is published).

Once Google shipped Atom 0.3 feeds, this option ceased to exist.

<Talk Small and Carry a Big Class Library>
James Robertson, Product Manager, Cincom Smalltalk
http://www.cincomsmalltalk.com/blog/blogView
[email-masked]

---

From: Robert Sayre <[email-masked]>
Date: Tue, 17 Aug 2004 15:19:14 -0400

> here... quite a few Atom 0.3 implementations out there that aren't internal...

Paul is suggesting that we do this for people publishing from the ietf 
draft specs (post-0.3).

As I understand it, the roadmap looks like this:

Atom 0.3
draft-ietf-atompub-00
draft-ietf-atompub-01
...
draft-ietf-atompub-NN
Atom 1.0

I believe that the goal is for there not to be another widely 
implemented draft until Last Call. Perhaps the chairs and secretary 
should explain this in more detail (I believe they have, I can't 
remember where to look).

My question is whether Mark N's proposal includes Atom 0.3. It's too 
late for that, IMHO. Aggregator authors have told us that consumers 
consider clients that don't support Atom 0.3 to be broken.

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Tue, 17 Aug 2004 13:22:45 -0600

> (or not anymore, once a new version is published).

I suspect that some developers who are anxious to get on the 
buzzword-compliance bandwagon may need to be tossed a bone to keep them 
placated till 1.0 arrives.  For example, we might put a note like those 
that have been suggested on the rest of the pre-1.0 drafts, with a note 
that if someone simply MUST deploy Atom now and will not be dissuaded, 
we recommend that they implement version 0.3 and NOT any other pre-1.0 
version, and that they prepare to drop 0.3 soon once 1.0 comes out.

On the plus side, if we can't dissuade people completely from deploying 
support for pre-1.0 versions, maybe we can at least get people to limit 
themselves to ONE pre-release version.

On the minus side, this might be misconstrued as an official stamp of 
approval on deployment of 0.3 if we don't do a good job of making it 
clear that it's not.

No matter what we do, I think we're going to have 0.3 floating around 
for a while.

---

From: Anne van Kesteren <[email-masked]>
Date: Tue, 17 Aug 2004 21:38:49 +0200

> Isn't the first step getting atomenabled.org taken off air?

Ehmm.. People are aware *a lot* of sites have Atom feeds? Blogger uses 
it as default. WordPress has it by default. MoveableType has it by 
default. NucleusCMS/BLOG:CMS has it by default. I believe Google news 
groups have Atom feeds.

You want to say the Atom project is temporary over? I guess the Atom WG 
should try to finalyse as soon as possible and as correct as possible 
and don't waste time in endless discussions about dates and other 
personal preferences.

(That all imho, of course.)

-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>

---

From: James Robertson <[email-masked]>
Date: Tue, 17 Aug 2004 15:32:04 -0400

>Any vendor who implements from anything other than the final IETF standard 
>will have a host of problems interoperating in the future. IETF documents 
>expire after six months, and are usually unavailable within nine months. 
>So, if someone releases code based on draft-ietf-atompub-format-07.txt, 
>that document will soon become unavailable, meaning that someone else 
>cannot determine how to interop with it in the future.

Umm, no.  I can tell you that for me, supporting a new rev of Atom (or RSS) 
is the addition of one class into my system.  No modifications to other 
code, and no impact on other code either.  All that matters to me is 
whether interim versions get used.  If they get used, then I have to 
support them.  If they don't, then I don't.  Words from the IETF are 
meaningless - it's what actually takes place that matters

>Of course, the RFCs we produce will live forever. You can still find RFC 1 
>on IMP software at <ftp://ftp.rfc-editor.org/in-notes/rfc1.txt> 35 years later.
>
>The Atompub WG *will* have proper and understandable versioning in both 
>the format and protocol before we are finished.
>
>Until the final, standardized version, the documents will make it clear 
>that implementers should only implement for internal use. If we find some 
>implementers creating feeds from pre-standards IETF drafts, a bit of quick 
>public education can probably fix the problem.
>
>--Paul Hoffman, Director

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 17 Aug 2004 12:43:15 -0700

>with 0.3 though, so I expect this to become a bigger problem when the next

Do you mean the first two Internet Drafts, or the final RFC?

>here... quite a few Atom 0.3 implementations out there that aren't internal...

There is some really-hard-to-miss education in the drafts.

--Paul Hoffman, Director

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 17 Aug 2004 13:22:01 -0700

>As I understand it, the roadmap looks like this:

Yes.

>implemented draft until Last Call.

No! We do not want wide implementation until after the IESG approves 
of draft-ietf-atompub-NN. There are many reasons for this:

- Having a dozen set of eyes with lots of protocol experience looking 
at the document often uncovers actual protocol errors that we just 
never noticed because we got too used to them.

- They may say "this doesn't work the IETF way, but it would be fine 
if you change it to that way" and we make the change

- They sometimes ask a really good question about a particular 
feature, and in our answering the question we fix something unclear 
in the document, and in doing that we find two pre-implementers who 
disagree, and we need to decide what "we" "really meant".

When the IESG sends -NN to the RFC Editor for publication, -NN 
becomes 1.0. We can even have a special half-step in there where the 
IESG says "we're fine with this draft except for the cruddy version 
number wording, so change that and off it goes." The editors do the 
final change and everyone knows that the new draft is Really It.

>  Perhaps the chairs and secretary should explain this in more detail 
>(I believe they have, I can't remember where to look).

It's not well-documented anywhere. This might go into a new version 
of the Tao of the IETF, of which I am also co-author...

>consider clients that don't support Atom 0.3 to be broken.

Fully agree.

We all have to live with the fact that Atom 0.3 is akin to RSS 0.9. 
Eventually, almost no creator software will emit it, but it will 
probably live on in reading software forever. The Internet is 
littered with such cases. For instance, most web browsers can still 
read Gopher sites even though almost no one has created one in over 
seven years.

Atom 0.3 had its purpose: it gave people something to talk about and 
look at before the Atom community came into the IETF. It showed that 
things were possible. It showed where there was massive disagreement. 
Atom 0.3 will exist forever, just like RSS 0.9 will.

It is not hard for us to prevent anything before Atom 1.0 to be 
deployed. The drafts are really clear about not implementing them. 
The folks on this list are really clear that we don't want them 
implemented. So far, we have been 100% successful in not having the 
drafts be implemented in an externally-visible way, and I don't see 
why that will stop until we tell the world "We think it's fully 
baked, and the IESG thinks it is fully baked, and we now have a 
reasonable version number and/or namespace, so now you can implement."

--Paul Hoffman, Director

---

From: Graham <[email-masked]>
Date: Tue, 17 Aug 2004 16:10:21 -0500

On 17 Aug 2004, at 2:38 pm, Anne van Kesteren wrote:

> You want to say the Atom project is temporary over?

No. My point was that there's a website run by the Secretary of this 
very Working Group that explicitly advocates people implement Atom 
support in shipping products. Would someone care to explain?

Graham

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 17 Aug 2004 22:26:43 +0100

> obligated to Dare Obasanjo arises from the above

Seems obvious enough to me, unless you care to weasel word from a 
position of complete pedantry. People have been "forced" to upgrade 
their aggregators since forever as I recall. Atom 0.3 is nothing new 
or special here. Perhaps you have a useful point to make, but I 
can't see it. Again, what do you suggest should be done?.

cheers
Bill

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 17 Aug 2004 15:08:14 -0700 (PDT)

--- Bill_de_hÓra <[email-masked]> wrote:
> their aggregators since forever as I recall. 

Please name these incidents. When have websites the
large readerships abandoned an existing syndication
format and forced users to upgrade their clients in
recent memory let alone being commonplace as you
imply? 

>Atom
> 0.3 is nothing new 

The point is painfully obvious. If your sites use Atom
0.3 you have to decide how you plan to react when Atom
1.0 ships and how this will affect consumers of your
syndication feeds. 

Based on the fact that some people were lauding Google
and others when they chose Atom 0.3 as the sole
syndication format for certain sites even though Atom
was not final makes it clear that not everyone
involved carefully considered the cost of that
decision. This discussion thread describes the cost of
these decisions from the folks who'll be on the front
line when sites like Blogger break users; the
aggregator authors. 

=====

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

---

From: Robert Sayre <[email-masked]>
Date: Tue, 17 Aug 2004 18:23:50 -0400

> support in shipping products. Would someone care to explain?

atomenabled.org shows people the following:

draft-nottingham-atom-format-02
draft-gregorio-09

aka Atom 0.3. The site doesn't even mention the IETF drafts.

You *ship* a product with Atom support. Says so in big letters right 
there on the homepage. I doubt you plan on removing that capability.

There's nothing wrong with implementing Atom 0.3.

Robert Sayre

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 17 Aug 2004 23:44:32 +0100

Dare Obasanjo wrote:

> Please name these incidents. 

I've upgraded or chnaged readers to read feeds as new formats 
appeared. Was I the only one? I doubt it. Am I the only exhibiting 
multiple feed formats? I doubt it.

> When have websites the

You're mixing matters to suit your argument. Is this a rant against 
Google's/Blogger's choices, a rant against atom version control, a 
rant against new formats a rant against Pilgrim, all the above?  I'm 
lost.

> The point is painfully obvious. 

Perhaps to you, certainly I'm none the wiser via this extended 
diatribe.

> If your sites use Atom

I'll add a new feed as I did for other RSSes. Which one people 
subscribe is their own business, whether I cut any of those feeds is 
my business.

> [ex-cathedra snipped]

What do suggest should be done?

cheers
Bill

---

From: Robert Sayre <[email-masked]>
Date: Tue, 17 Aug 2004 18:44:00 -0400

> 1.0 ships and how this will affect consumers of your

Do you have an idea other than redirecting after a suitable period of 
time? What would you like to see producers do?

> 
> This discussion thread describes the cost of

This discussion is growing melodramatic. In the event that a site 
"breaks users", don't you think the site would hear about it as well? 
Their authors must be using an aggregator. Everyone is "on the front line".

Robert Sayre

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 17 Aug 2004 15:47:55 -0700 (PDT)

> time? What would you like to see producers do?

I'd like producers to wait until Atom 1.0 until they
deploy Atom. If they already have deployed previous
versions redirecting after a suitable period of time
is a decent solution. Some people will be
inconvenienced but it can't be helped at this point. 

=====

__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 17 Aug 2004 16:36:48 -0700

>inconvenienced but it can't be helped at this point.

+1

--Paul Hoffman, Director

---

From: Tim Bray <[email-masked]>
Date: Tue, 17 Aug 2004 16:44:18 -0700

On Aug 15, 2004, at 3:21 PM, Mark Nottingham wrote:

> clearly state that they're not to be implemented, and are superseded 
> by the work here.

Thanks Mark, and thanks for raising the issue here, I thought the 
discussion was really useful.  There seems fairly widespread agreement 
that:

1. Atom 0.3 is out in the wild, implementations of it will live as long 
as the gopher support still there in modern browsers.  It's been 
useful.
2. We should try really hard to keep any interim versions this side of 
1.0 from escaping into the wild [modulo the fact that the release of 
v1.0 of anything is a punctuated, jerky, non-atomic event]; so far 
we're doing OK on this.
3. Atom 1.0 is probably going to be substantially incompatible with 0.3 
in several respects and that's OK.
4. We should hurry up and get this done.

If anyone observes any leakage of post-0.3 pre-1.0 versions, please 
shout loudly and continuously and we'll see what community pressure can 
do.  When 1.0 ships, we should all join together and use the 
(considerable) power of our public voices to get the world to start 
switching over.

  -Tim

---

From: James Robertson <[email-masked]>
Date: Tue, 17 Aug 2004 19:57:01 -0400

As a content producer, what advantage would there be in switching to Atom 
1.0?  Given that every aggregator supports (and will continue to support) 
RSS 2.0, and given that I want to make it as easy as possible to be read, 
what good reason would there be for me to switch?  Heck, what good reasons 
would there be for adding Atom 1.0?

This isn't intended to be a negative comment, actually.  It would be useful 
to have an answer to these questions - because the easiest thing to do as a 
content producer is exactly what I do now....

>If anyone observes any leakage of post-0.3 pre-1.0 versions, please shout 
>loudly and continuously and we'll see what community pressure can

---

From: Walter Underwood <[email-masked]>
Date: Tue, 17 Aug 2004 17:11:11 -0700

--On Tuesday, August 17, 2004 4:44 PM -0700 Tim Bray <[email-masked]> wrote:
>
> If anyone observes any leakage of post-0.3 pre-1.0 versions, please shout loudly and continuously and we'll see what community pressure can do.  When 1.0 ships, we should all join together and use the (considerable) power of our public voices to get the world to start switching over.

Again, I suggest that the drafts specify <atom-draft> (or <feed-draft>)
to identify any such leakage.

wunder

---

From: Graham <[email-masked]>
Date: Tue, 17 Aug 2004 19:17:23 -0500

> There's nothing wrong with implementing Atom 0.3.

Mark Nottingham, at the start of this thread:
"I've just changed the old, pre-WG drafts ... to clearly state that 
they're not to be implemented ... One of the things that drove me to do 
this is the increasing incidence of vendors shipping products and 
services that "support" Atom, even though it's clearly marked as a 
pre-draft"

Once again, why is atomenabled.org still online if we don't want people 
implementing? And Robert, are you seriously saying there's nothing 
wrong with encouraging people to write new implementations of Atom 0.3 
today?

(I wrote my Atom 0.3 implementation at least in part because of that 
website, if it counts for anything)

Graham

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 17 Aug 2004 17:40:34 -0700

This question has been on my mind, too; thanks for pointing it out.

We need to have a clear idea of what's going to compel people to switch 
to Atom. I would put forth that the most valuable thing -- from content 
producers' standpoints -- is predictability of behaviour in aggregators 
and other consumers, so they *know* how their feed will appear. Not 
cosmetically, but functionally.

This is why I think issues like managing feed state are so important. 
The actual functionality we provide is less critical than the 
consistency of its use across different consumers.

This doesn't mean that all aggregators have to look the same and offer 
the same bland view of the data; it's just that the data must be 
reproduced faithfully. For example, if aggregator one keeps a history 
of items in the feed, and it marks different ones as 'new' than 
aggregator two does, there's clearly a problem.

I think we have a unique opportunity here, in that a great majority of 
the vendors interested in writing products that consume Atom are at the 
table and willing to work together. This can translate into a clear win 
over existing technology if we can agree on what an aggregator is, what 
a feed is, and how they interact*.

This, IMO, is what we should be working towards. The alternative is 
just as you say -- a repeat of RSS with a few changes that only people 
here care about.

Cheers,

* There is a tension here, in that IMO we shoudn't say that Atom is 
ONLY for aggregators; that's why I've consistently advocated building a 
logically separate profile just for the common aggregator/blog 
situation.

On Aug 17, 2004, at 4:57 PM, James Robertson wrote:

> As a content producer, what advantage would there be in switching to 
> Atom 1.0?  Given that every aggregator supports (and will continue to 
> support) RSS 2.0, and given that I want to make it as easy as possible 
> to be read, what good reason would there be for me to switch?  Heck, 
> what good reasons would there be for adding Atom 1.0?
>
> This isn't intended to be a negative comment, actually.  It would be 
> useful to have an answer to these questions - because the easiest 
> thing to do as a content producer is exactly what I do now....

---

From: Robert Sayre <[email-masked]>
Date: Tue, 17 Aug 2004 20:52:20 -0400

> services that "support" Atom, even though it's clearly marked as a 

http://www.mnot.net/drafts/draft-nottingham-atom-format-02.html

So the deadline has passed for writing an Atom 0.3 parser?

I don't get it. There are millions of Atom 0.3 feeds out there, and 
implementors aren't supposed to support them because of a retroactive 
decision by the editor based on his perception of their mass-marketness? 
Yeah, I dunno...

> implementing? And Robert, are you seriously saying there's nothing wrong 
> with encouraging people to write new implementations of Atom 0.3 today?
> 

Let's assume a producer wants to migrate to Atom 1.0 eventually. It 
doesn't matter what they choose now. They will still face migration 
issues. Besides Atom 0.3 is more stable than RSS 2[0]. Meanwhile, I'm 
still seeing "<cite>" in the titles of my RSS feeds from The Register.

Thunderbird 0.8 and Mac OS X 10.4/Safari 2.0 are going to ship with Atom 
0.3 support. Who wants to write the email that tells them they have to 
support fewer feeds than Shrook, RSS Bandit, FeedDemon, NNW, etc?

Robert Sayre

[0] http://blogs.law.harvard.edu/tech/rssChangeNotes

---

From: James Robertson <[email-masked]>
Date: Tue, 17 Aug 2004 20:59:44 -0400

At 08:52 PM 8/17/2004, you wrote:
>At 7:57 PM -0400 8/17/04, James Robertson wrote:
>>1.0?
>When we get close to finishing, we'll have a better answer. For now, there 
>is nothing we can say definitively because we don't know what the final 
>specs will look like.

That's a pretty lame answer, to be honest.  What advantages would you 
expect there to be?

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 17 Aug 2004 17:52:25 -0700

At 7:57 PM -0400 8/17/04, James Robertson wrote:
>As a content producer, what advantage would there be in switching to Atom 1.0?

When we get close to finishing, we'll have a better answer. For now, 
there is nothing we can say definitively because we don't know what 
the final specs will look like.

--Paul Hoffman, Director

---

From: Dan Brickley <[email-masked]>
Date: Tue, 17 Aug 2004 21:02:30 -0400

* Mark Nottingham <[email-masked]> [2004-08-17 17:40-0700]
> cosmetically, but functionally.

This is an interesting discussion to have. I'm interested to hear
whether the AtomPub WG expect an Atom 1.0 document format to be 
able to do everything that RSS 1.0 can do (and more, presumably).

I've tended to see Atom as being optimised for weblogging use cases, at 
the possible expense of the general-purpose extensibility that RSS 1.0
enjoys. But maybe it'll do both...?

dan

---

From: Mark Pilgrim <[email-masked]>
Date: Tue, 17 Aug 2004 21:27:22 -0400

On Tue, 17 Aug 2004 19:17:23 -0500, Graham <[email-masked]> wrote:
> they're not to be implemented ... 
> 
> implementing?

Obviously, Mark Nottingham has gone off on his own here, and modified
his pre-draft in place nine months after it was first issued. 
Honestly, these kind of shenanigans are what we rightly bitched about
when we saw the same sort of behavior in the RSS community.  It's one
of the main reasons we sought stewardship in a stable standards
organization -- because individual spec maintainers can't be trusted.

I'm not saying Mark should be removed from editorship, but if you were
inclined to make a list, I would expect you would add this to it.

Meanwhile, Mark has no influence over atomenabled.org, which is
primarily a marketing site and is maintained by early adopter vendors.
 AFAIK, that site has no official relationship to the Atom Working
Group, so I expect they can and will say whatever they damn well
please.

-- 
Cheers,
-Mark

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 17 Aug 2004 18:30:01 -0700

On Aug 17, 2004, at 5:52 PM, Robert Sayre wrote:

> decision by the editor based on his perception of their 
> mass-marketness? Yeah, I dunno...

Implementers can do what they like; nothing can constrain their 
activity, unless they break the law or a contract.

As the owner of mnot.net, I can do literally anything I like with that 
draft. Note that I implicitly own the copyright on itif push comes to 
shove. Scared? Anybody relying on that spec should be. Let's not even 
mention that it's massively under-specified, and I'd imagine that it 
manages to contradict itself too.

Does this situation sound familiar? It should. Will it stop some 
implementers from using it? Probably not, but why should they be 
encouraged to persist in doing so?

The whole reason we're here is to do this work under the auspices of 
the IETF, so it has the stability, change control, buy-in, completeness 
and technical review that implies. Let's not jump the gun.

Regards,

---

From: Mark Pilgrim <[email-masked]>
Date: Tue, 17 Aug 2004 21:33:01 -0400

> support in shipping products. Would someone care to explain?

Sam and I "run" http://feedvalidator.org/ which explicitly "validates"
Atom 0.3 feeds against Mark Nottingham's 0.3 pre-draft.  Should we
shut this down too?

By the way, in case you hadn't noticed, I also "run" several sites of
a personal nature on the same server as the feed validator.  Obviously
these reflect poorly on the working group and should be shut down
ASAP.

Also, I have from time to time been less than speedy in my denials of
accusations that I kill kittens.  It's obviously a BigCo conspiracy.

-- 
Cheers,
-Mark

---

From: Robert Sayre <[email-masked]>
Date: Tue, 17 Aug 2004 21:47:58 -0400

Mark Nottingham wrote:

> shove. Scared? 

No. Delete it. Let's see 410 at work!

Is the status of the Atom 0.3 draft on-topic for this list or not?

Robert Sayre

---

From: Mark Pilgrim <[email-masked]>
Date: Tue, 17 Aug 2004 22:00:17 -0400

On Tue, 17 Aug 2004 18:30:01 -0700, Mark Nottingham <[email-masked]> wrote:
> shove.

If someone were making a list of reasons to remove you from
editorship, I would definitely expect them to add that statement to
the list too.

-- 
Cheers,
-Mark

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 17 Aug 2004 19:43:55 -0700

At 8:59 PM -0400 8/17/04, James Robertson wrote:
>That's a pretty lame answer, to be honest.  What advantages would 
>you expect there to be?

Wow, an engineer is *asking* for a marketing shpiel. :-)

- We expect it to be tigher and better-defined than previous RSSs so 
that there will be better long-term interoperability.

- We expect there to be standard features like publishing and 
autodiscovery that will help Atom users in ways that are unavailable 
in previous RSSs.

- We expect that the extensibility will be cleaner and better defined 
so that small markets will be able to use Atom easier than previous 
RSSs.

None of that might spin your beanie. One big reason many of us are 
working on Atom is that we believe that RSSish syndication can become 
a major communication mechanism for literally decades to come (look 
at RFC 822 and MIME, for instance). If that is true, it should have 
the most polished, most reviewed, and clearest spec possible.

--Paul Hoffman, Director

---

From: Tim Bray <[email-masked]>
Date: Tue, 17 Aug 2004 20:24:28 -0700

On Aug 17, 2004, at 5:40 PM, Mark Nottingham wrote:

> We need to have a clear idea of what's going to compel people to 
> switch to Atom. I would put forth that the most valuable thing -- from 
> content producers' standpoints -- is predictability of behaviour in 
> aggregators and other consumers, so they *know* how their feed will 
> appear. Not cosmetically, but functionally.

I have three real pain points around RSS:

1. I see way too many dupe articles
2. The markup escaping is too easy to get wrong
3. The APIs are kludgy and have interoperability problems

I think Atom has a chance to make all those pain points go away and 
provide a compelling incentive for content providers to move to Atom.  
Of course, this will only reveal the next set of irritating pain 
points, but that's life.  -Tim

---

From: Dan Brickley <[email-masked]>
Date: Wed, 18 Aug 2004 03:47:24 -0400

* Paul Hoffman / IMC <[email-masked]> [2004-08-17 19:43-0700]
 
> so that small markets will be able to use Atom easier than previous 

Really? That'd be great, but I've not seen much evidence that 
the WG takes that view. I'm comparing with RSS 1.0's RDF/XML-based
extensibility framework; the other flavours don't really have one,
except for RSS 2.0's "use namespaces and you're on your own".

Extensibility comes at a price, and designing something cleaner and
better than RDF will be an interesting endeavour. Finding a clean and 
syntactically graceful way of mapping _into_ RDF also comes at a price, 
as does (of course) simply using full RDF/XML syntax. The pre-IETF 
Atom community decided some time ago that they didn't find RDF/XML 
an attractive proposition, which I guess means we're going the route of 
defining an extensibility model that is somehow better than RSS 1.0's.

Hmm so what were the key benefits of RDF extensibility in RSS 1.0? 

 - (fairly) predictable XML notation; RSS 1.0 defined a profile of the 
   RDF/XML syntax, so that namespace-extended feeds all shared a 
   basic structure. (rather than allowing all RDF's syntactic
   variations).

 - Supported free combination of independently developed descriptive 
   vocabulary (manifested as RDF/XML-based namespaces). RSS 1.0 feeds 
   can carry extra markup describing things in the world beyond
   syndication, such as people, places, movies, bank accounts. Element 
   names in the markup correspond to classes (categories) and properties 
   (fields, relations etc) defined by any RDF vocabulary that proves 
   useful.

 - The external vocabularies a feed draws upon do not need to be defined 
   with RSS 1.0 (or Atom or newsfeed syndication) in mind. Or be tightly 
   coordinated amongst themselves. There is a tightly-defined model and 
   simple-minded (additive) model for explaining how these independent 
   namespaces interact when deployed together.

What were the problems / drawbacks with RSS 1.0's RDF extensibility?

 - explaining the XML-level constraints on markup structures amounted 
   to the need to present a mini-tutorial on RDF's syntax rules, since 
   RSS 1.0 used RDF's standard XML encoding.  This involves unenviable 
   tasks like explaing RDF's "striped" XML style (see 
   http://www.w3.org/2001/10/stripes/ ), and trying to summarise the 
   rules for when you use "rdf:about=" versus "rdf:resource="
   attributes.

 - when RSS 1.0 shipped (4 years ago) there weren't many RDF
   vocabularies, software libraries were less mature, and the RDF
   specs hadn't gone through the RDFCore cleanup (which finished Feb'04).
   Sites like http://www.schemaweb.info/ show that there are a 
   growing number of vocabularies, but many are still a bit drafty.

 - RSS 1.0 was perhaps a little too minimalist, forcing people to use 
   extensions for things that a broader syndication-oriented vocab 
   could have included in a more generous core.

 - The only widely used extension for carrying hypertext content in 
   RSS 1.0 was 'content:encoded', which somewhat opts-out of 
   the XML world. RDF in 2000 was a bit vague on how to deal with 
   namespaces, xml:base, xml:lang  andther canonicalisation issues 
   relating to "literal XML" content. (addressed in Feb'04 specs)

 - the blogging use case (which dominated RSS deployment and evangelism)
   didn't have as much to gain from a powerful extensibility framework
   as those apps which sometimes get called 'synthetic feeds'.

> the most polished, most reviewed, and clearest spec possible.

Yes, that's what draws me to RSS 1.0 and its siblings. One lesson from 
the non-blogging use cases (job adverts, movie listings, bank account
feeds, etc.) that get some of us enthused is that the most interesting 
bits of the markup are those which use (possibly various) non-RSS 
namespaces. RSS is the least interesting, and simplest, part of the
document.

I think the recently announced "Nature" RSS 1.0 feeds might repay study, 
as a way of thinking about the tradeoffs around AtomPub's extensibility
goals.

See http://www.nature.com/rss/

There are feeds there from scientific journals, and for job listings in 
the sciences. The extensions used are both useful, and evocative. They 
immediately suggest further extension ideas. 

eg. http://www.nature.com/nrc/journal/v4/n8/rss.rdf
[[
<item rdf:about="http://dx.doi.org/10.1038/nrc1424">

    <title>TUMOUR VIRUSES: A genetic switch</title>
    <link>http://dx.doi.org/10.1038/nrc1424</link>
    <description>Kristine Novak</description>
    <dc:title>TUMOUR VIRUSES: A genetic switch</dc:title>
    <dc:creator>Kristine Novak</dc:creator>
    <dc:identifier>doi:10.1038/nrc1424</dc:identifier>

    <dc:source>Nature Reviews Cancer 4, 572 (2004)</dc:source>
    <dc:date>2004-08-01</dc:date>
    <prism:publicationName>Nature Reviews Cancer</prism:publicationName>
    <prism:publicationDate>2004-08-01</prism:publicationDate>
    <prism:volume>4</prism:volume>
    <prism:number>8</prism:number>

    <prism:section>Highlights</prism:section>
    <prism:startingPage>572</prism:startingPage>
</item>
]]

or, more interesting: http://www.nature.com/naturejobs/jobs/biologicalsciences.rdf
[[
<item
rdf:about="http://naturejobs.nature.com/texis/jobsearch/details.html?id=411109c54a01090&amp;lookid=nature">
<title>University of Sheffield: Research Associate</title>
<link>http://naturejobs.nature.com/texis/jobsearch/details.html?id=411109c54a01090&amp;lookid=nature</link>

<description>Research Associate, University of Sheffield, Sheffield,
United Kingdom.  Posted on 4 August 2004.</description>
<nj:advertises>
<nj:Job>
<nj:offeredBy>University of Sheffield</nj:offeredBy>
<nj:title>Research Associate</nj:title>
<nj:city>Sheffield</nj:city>
<nj:country>United Kingdom</nj:country>
</nj:Job>
</nj:advertises>
<nj:postedOn>2004-08-04</nj:postedOn>
<nj:expiresOn>2004-09-02</nj:expiresOn>
</item>
]]

So already we're talking about the syndicating online representations of 
articles, digital rights, page numbers, authors, cancer, jobs, cities, 
locations and expiry dates for job applications. All of those things 
are (a) beyond the immediate and future scope of the AtomPub group (b)
described in different levels of detail by different parties for
different purposes. Eg. jobs are based in places; they have associated
skills, which might be picked out in cross-domain subject schemes or in 
domain specific details; places have lat/long info, which can be
modelled in painful detail or very crudely. XML description here is a
task without end, because we're trying to create a marketplace where it
is possibly for increasingly rich descriptions to be mixed together 
in as sane a fashion as possible.

I'd be interested to take this
http://www.nature.com/naturejobs/jobs/biologicalsciences.rdf feed as a
test for AtomPub's extensibility goals. Would we hope to do a
cleaner/better job than RSS 1.0 here. Perhaps in the future,
scientifically minded job hunters will be able to go do a search on jobs 
in their particular speciality and see the results using
geographically-oriented tools. I'd love to see Atom become a transport
for all this...

cheers,

Dan

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 18 Aug 2004 01:24:45 -0700 (PDT)

--- Dan Brickley <[email-masked]> wrote:
>
> I'm comparing with RSS 1.0's
> RDF/XML-based

I am suspicious of any claims that RDF buys you more
extensibility than using XML and namespaces in
practice. See
http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=5b31837c-49cc-4d1d-9f14-fd25df8b54f2
for details. But let's go on... 
 
> The pre-IETF 

How is this practically useful? The fact that an
extension will show up as single elements with simple
content or as elements with attributes and complex
contents doesn't bring my application any closer to
understanding them when encountered in the wild. 

>    (fields, relations etc) defined by any RDF

I see this in RSS 2.0 as well. 

>    namespaces interact when deployed together.

I see this in RSS 2.0 as well. 

>    as those apps which sometimes get called

So far you have listed a bunch of drawbacks of the RDF
based approach used by RSS 1.0 and none of the
benefits that haven't been seen using just XML and
namespaces in RSS 2.0. 

=====

---

From: Danny Ayers <[email-masked]>
Date: Wed, 18 Aug 2004 11:47:20 +0200

> practice. 

(I expect Dan will respond - still, here's another couple of cents) 

I'm a little surprised to find that you still hold this opinion, but
ok, by way of example. Say you wanted your RSS entry to describe a
project. In RSS 2.0 you might have something like:

<item>
<guid>http://example.org</guid>
<title>My Project</title>
<x:Project>
	<x:name>My Project</name>
	<x:homepage>http://example.org/home</x:homepage>
<x:Project>
</item>

In RSS 1.0 it might look like:

<item rdf:about="http://example.org">
<title>My Project</title>
...
</item>

<doap:Project rdf:about="http://example.org">
	<doap:name>My Project</name>
	<doap:homepage rdf:resource="http://example.org/home" />
</doap:Project>

If the  consumer understands the project vocabulary, then full
communication can take place with either version. However, assume the
consumer knows nothing about the project extension.

If the consumer understands RDF/XML syntax, then from the RSS 1.0
version it can determine that:

1. the item resource is an instance of the class doap:Project
2. the item has a literal property, doap:name with the value "My Project"
3. the item has a property with a resource as it's value, the URI
being "http://example.org/home"
4. that doap:Project is an rdfs:Class
5. that doap:name is an rdf:Property with a domain including doap:Project 
6. that doap:homepage is an rdf:Property with a domain including doap:Project
7. that doap:homepage is an rdf:Property
(and a few other bits)

If the consumer is aware of the RDF Schema for doap, then it also has
access to other information, for example that doap:name is an
rdfs:subPropertyOf rdf-schema#label". This could be used to decide how
to render the value for display.

If the consumer understands RSS 2.0, XML and namespaces, then it still
understands absolutely *nothing* about the project information, not
even that it applies to the same item.

Partial understanding is only one advantage, another big one is that
RSS/RDF vocabularies can be mixed and matched with impunity and still
carry that partial understanding (if fact, combined partial
understanding of all the parts). On the other hand, mixtures of
arbitrary combinations of RSS 2.0-based extensions are undefined, and
there is nothing to prevent conflicts in their interpretation
(namespaces separate the terms, but conflicts may appear at a higher
level in the app).

See also:

http://www.xml.com/pub/a/2003/07/23/extendingrss.html

Cheers,
Danny.

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 18 Aug 2004 10:41:19 +0100

> understanding them when encountered in the wild. 

Speaking as an avowed and somewhat loudmouthed RDF cynic.

It's useful because one can add new data items to markup with 
breaking existing code downstream. Whether you want to add code to 
meaningfully process those data items is another matter. You seem to 
be deliberatly mixing those two things up, or perhaps you don't 
understand the difference. In my experience XML+namespaces doesn't 
provide anything like that. Quite the opposite it's sufficiently 
fragile to almsot assure breakage down stream and down time, so much 
so entire communities are encouraged to figure out a sensible means 
to layer extensibility onto schema driven XML documents, something 
that we'll be doing here soon enough no doubt. Much of this 
fragility I see as I suspect is a direct result of people believing 
that XML+namespaces have some magical properties of extensibilty and 
getting bitten later on.

> benefits that haven't been seen using just XML and

That's makes so little sense it's not even wrong. When it comes to 
extensibility or flexibility in markup, making these sorts of claims 
around "just XML and namespaces" is bunk. For example, I've read 
yours and others useful articles and papers on extensibility. Yet 
that's not just XML and namespaces, that's an entire added semantics 
on top "of just XMl and namespaces" *and* schemata. So really you're 
comparing RDF/RSS1.0 with "just XML and Namespaces" and schema and a 
lot of other articulated processes and constraints. We here, already 
have XML+namespaces for Atom, remind me again why we need a model 
extensilbilty?

In OO terms, the difference between RSS1.0 and all the others is 
very like the difference between programming with 
reflection/hashmaps and programming with domain specific objects. 
Both have their uses, bth have their drawbacks. The primary tension 
in my experience there is a balancing act to conduct between the 
flexbility provided by something like RDF versus the clarity of 
domain specific markup. Raw RDF is not neccessarily comprehensible 
with respect to a 'domain model', raw XML+Namespaces is not 
neccessarily flexible with respect to 'change'. I suspect it helps 
to have tried both approaches rather than simply looking at them and 
opining to appreciate this.

cheers
Bill

---

From: Sam Ruby <[email-masked]>
Date: Wed, 18 Aug 2004 07:52:57 -0400

> defining an extensibility model that is somehow better than RSS 1.0's.

If you were to express that paragraph as a set of assertions, you would 
find something missing.  I'm going to extract a few, please forgive my 
inprecise way of expressing them:

   RSS 1.0 uses RDF.
   RDF addresses some extensibility problems.
   RDF/XML is a serialization syntax for RDF.
   pre-IETF community didn't find the RDF/XML syntax attractive.

What can we conclude from this?

First, for purposes of this discussion, lets not debate the assertion 
that RDF addresses extensibility issues, and simply treat it as a given. 
  And let's assume, again for purposes of discussion, that the AtomPub 
working group is interested in pursing a non-RDF/XML serialization syntax.

Even with all these assumptions, can we conclude that "we're going the 
route of defining an extensibility model that is somehow better than RSS 
1.0's."?

I don't think so.

Hint: there are other serialization syntaxes than RDF/XML.

Further reading:
   http://www.xml.com/pub/a/2003/08/20/dive.html
   http://semtext.org/atom/utils.html
   http://www.w3.org/2004/01/rdxh/spec

- Sam Ruby

---

From: Dan Brickley <[email-masked]>
Date: Wed, 18 Aug 2004 08:11:23 -0400

* Dare Obasanjo <[email-masked]> [2004-08-18 01:24-0700]
 
> understanding them when encountered in the wild. 

We're not talking AI here. Just data mixing and a decentralised 
division of labour.

RDF's contribution is really a strategy for decentralising vocabulary
design. When someone designs an RDF vocabulary, the things they name 
and describe in their namespaces are classes (categories) and
properties (relationships etc.). When someone designs an XML vocabulary,
the things they name and describe in their namespace are XML elements and 
attributes. In the RDF case, the vocabulary is described in terms of the
world; you say things like "'wrote' is a relationship between an 'Agent'
and a 'Work'", or "'JPEGImage' is a sub-class of 'Image'"; in the XML
case, you talk more explicitly about markup patterns, rather than about
the things that markup tells you about the world. So we end up with 
committees and groups inventing XML markup, and their primary means 
of expression is the ability to say, basically, which XML elements can 
live inside which other XML elements, in what order, and which attributes
they are allowed to be decorated with. And there are half a dozen schema 
languages these guys can use to do that job in slightly different ways.
All RDF namespaces, by contrast, are based on the RDF Schema approach
(perhaps using the OWL extensions).

My problem with the "let them eat namespaces" view is that it ignores
the social mechanics that gets us this mixed-namespace markup in the
first place. I'm perfectly willing to believe that one could write 
XQuery or XSLT or DOM+.js to consume mixed markup, *assuming* that some 
collection of parties had figured out conventions for mixing their
namespaces together. But that more takes time, effort and money to 
achieve at a fine grained level if you opt-out of the RDF infrastructure. 
Non-XML namespaces can sit alongside each other in an XML tree, or live
one inside the other, but generally we've seen precious little by way of 
freely mixable XML namespaces. By contrast, *all* RDF vocabularies can
be deployed in a mixed way, out of the box, because RDF indirects
through a common data model and XML encoding which imposes some common
conventions across otherwise indpendent vocabularies. 

The idea that different parties "simply create their own XML namespaces"
is problematic because the world doesn't come organised into nicely 
parceled, crisply discrete problem spaces, each with their own
MyProblemSpaceML markup notation. Things are horribly jumbled up 
(which is why AI failed to deliver, imho).

So you think you're working on a "digital images" markup language 
for photos, and you find you're spending half your time thinking 
about geographic markup, or representing the content of the picture, 
or fending of motionpicture people who claim your problem space 
is subsumed by theirs. You think you're working on geographic 
markup, places and coordinates and maps,
and find yourself drawn into modelling the things that are on the map.
You think you're creating bibliographic metadata but find it to be 
intimately tangled up with rights metadata, with educational level
classification metadata (which btw crops up again if you're doing jobs,
CVs, and personal profile work (and which varies wildly between
countries)). Everything is jumbled up with everything else, and so we
need some conventions for people to get out there and do their bit
without waiting for everyone else to finish the other bits of the
puzzle. 

Should the folk doing Job advert markup have a meeting with the people
doing geo markup or postal addresses, to decide whose tags can go in
whose, and update their schemas accordingly? What about CVs? Photos?
Bibliographies, educational metadata, rights, and so and so on? I got on
board the RDF train after being burnt out from attending so-called
metadata initiative meetings (primarily biblio, imaging, education,
search) where people were merrily creating tagsets whose scope and
features overlapped and who badly needed a bit more architecture for
fine grained mixing, so they could concentrate better on their area of
expertise, and leave the detail of other areas to be fleshed out by 
folk with complimentary exercise. Without having to sit around a table
with them arguing about XML tag nesting structures.

This is not, and shouldn't be mistaken for, the old AI dream of 
machine intelligence. It's simply a wish to have to fly around to fewer 
standards coordination meetings. And to do that, we need some high level
things that all XML namespaces have in common. Whether tag order is
significant, for example (in RDF, it almost always isn't). Whether
there's negation-as-failure closed world assumptions (in RDF, we avoid
this), a convention for knowing whether an element stands for a category
of thing, or a kind of relationship between things, etc etc. 

There are several options. We can hope that people somehow create XML
namespaces that play well together, in the absence of such conventions.
This hasn't happened yet, but there's always hope. Or we can try to 
invent some such conventions within the AtomPub WG (add
11-24 months to the schedule; plus same again 2 years later to fix
mistakes), or we can back off from the 'Atom everywhere' rhetoric and 
decide that Atom's really about interop in the blogging world, and 
that full on data syndication is a v2.0 problem, and that v1.0 targets
bloggers.

When feeds are carrying rich namespace-extended descriptions of the things 
the feeds describe (jobs, journals, products, holidays, pornography, people, 
cities, mail messages, CVS servers, journal articles, paper-published 
books, MP3s, Ogg streams, playlists, concert listings, weather reports, security
alerts, blog comments, answerphone messages, bank transactions, network
outages, TV schedules, dentist appointments, football results, product
recalls, train times, blind dates, press releases and -yesyes- blog posts, 
... *then* we'll have 'atom everywhere'. But unless we're going to slip 
back 5 years in terms of expressivity, Atom needs a way to allow all
these kinds of thing to be described using whatever externally-managed
namespaces make sense in the marketplace.

For externally managed namespaces to make sense when deployed together, 
they need to be designed with that in mind. Which brings us back to 
the frameworks on offer to folk creating those namespaces. The examples
I gave above are mix. There's some blogging and information-resource use
cases in there (though digital library stuff quickly shades off into
complexity). There's a lot of things focussed around people, around
places, and in particular around events. Hardly suprising; syndication
is event-centric. Not blog posting events, but events in the world that 
are associated in various (potentially nameable) ways with the information 
items we syndicate in XML. The AtomPub WG isn't (AFAIK) in the 
business of providing exhaustive descriptions of events, of places, 
of people. It is, perhaps, in the business of providing a syndication 
framework where richer descriptions of these things (and more) can be 
mixed together. This doesn't mean that all Atom code needs to understand 
them, or will magically become intelligent and able to act upon new markup. 
Just that there could usefully be a few common patterns for mixed-namespace 
markup which allow the ***huge*** task of describing all this stuff to 
be divided up amongst parties who may never meet or even be working on their
namespaces at the same time. (I like the OpenGALEN slogan here; "making the 
impossible very difficult" ;)

So we should always be thinking about how to divide up the work, ie.
what can we say to people who want to contribute a better way to
describe jobs, drawing upon existing work re skills description, topics,
location? What to say to people who want to syndicate photo metadata,
drawing upon lat/long markup, 'who is in this photo' markup, common
nouns, EXIF fields, and so on. Do we encourage them to have anything in
common with each other's efforts, or just say "use XML+namespaces, go
invent some named elements and attributes and tell us what markup
patterns you consider valid".

If they go the vanilla XML+namespaces route, they get
to pick some named XML elements and attributes, and say some stuff about
which element combination patterns are allowed, and how they can be
decorated with XML attributes. If they go the RDF route, they don't get
asked which elements theirs can go inside, and which can go inside
there, **because it isn't up to them**. RDF quite explicitly witholds that
ability from the creators of a namespace, so that we don't force people
to anticipate all future uses of their creation, or get into rigid and
fragile versioning coalitions with owners related tagsets. (and no, RDF doesn't
solve the namespace versioning problem, but it makes it approachable, or
at least merely very hard).
 
The RDF approach isn't trying to make data universally understandable in
any fancy AI sense, just universally mixable. If I want to aggregate jobs
data, I need to know a bit about Jobs-related namespaces. If I want a 
really smart Jobs aggregator, I'll go and investigate namespaces that
relate to places, to events/time, to skill and topic description, and to
geography. And I'd be well-advised to create some nice tools that
actually use that data, and go evangelise those extensions to parties
who'll create enough feeds to get some adoption. No magic, just a bit of
structure around a lot of hard work.

> I see this in RSS 2.0 as well. 

RSS 2.0 says "how these namespaces get designed and how they play
together isn't our problem". Which brings us back to the scoping
question. If AtomPub's deliverable is really focussed around weblogging, 
then maybe it's OK to say "we don't know yet; maybe in Version 2". But
if Atom is to be marketed as the backbone for Web-based data
syndication, establishing a framework that'll serve us for decades to
come, then the "not our problem" approach to mixed-namespace design
simply doesn't cut it.

cheers,

Dan

---

From: Dan Brickley <[email-masked]>
Date: Wed, 18 Aug 2004 08:20:51 -0400

* Sam Ruby <[email-masked]> [2004-08-18 07:52-0400]
> What can we conclude from this?

(That the baby is at risk because of the bathwater? ;)

>   http://www.w3.org/2004/01/rdxh/spec

Yes. I skirted this a little, but that's an important message: 
it would be unfortunate to confuse RDF with it's current/primary
XML serialization (aka "RDF/XML").

BTW things are moving along with GRDDL, it is now published as a 
W3C Note, http://www.w3.org/TR/2004/NOTE-grddl-20040413/
(GRDDL, briefly, provides some conventions for pointing to an XSLT that 
turns some markup into RDF/XML).

The XHTML folk have also just shipped a Working Draft that shows a 
revision to the <link/> and <meta/> constructs in a way that allows 
it to be treated as an alternate XML notation for RDF graphs. See 
http://www.w3.org/TR/2004/WD-xhtml2-20040722/mod-metaAttributes.html#s_metaAttributesmodule
http://www.w3.org/TR/2004/WD-xhtml2-20040722/mod-meta.html#s_metamodule

Needless-ish to say, ongoing work on RDF querying
(http://www.w3.org/2001/sw/DataAccess/) is agnostic about RDF concrete
syntaxes, since it is couched in terms of the graph data model. The same
goes for all the vocabulary namespaces listed at
http://www.schemaweb.info/

cheers,

Dan

---

From: James Robertson <[email-masked]>
Date: Wed, 18 Aug 2004 09:41:33 -0400

At least in my case, the cost to support that kind of extension is 
identical - so RDF buys me nothing.

---

From: Antone Roundy <[email-masked]>
Date: Wed, 18 Aug 2004 09:03:48 -0600

On Wednesday, August 18, 2004, at 03:47  AM, Danny Ayers wrote:
> In RSS 2.0 you might have something like:
>
> <item>
...
> even that it applies to the same item.

After thinking about this briefly and realizing what it meant (I 
think), this became the single most interesting point yet to come out 
of this discussion.  Allow me to make another example (with some 
fanciful elements and structure) to illustrate the point and see if I 
understand it correctly:

<item>
	<title>My title</title>
	<author>
		<name>Joe</name>
		<url>http://www.joe.com/</url>
	</author>
	<colors>
		<text>blue</text>
		<background>white</text>
	</colors>
</item>

 From this, we know that the item has an author and colors, but what do 
the elements inside <author>...</author> and <colors>...</colors> 
describe?  The author, or the item?  The "colors", whatever that is, or 
the item?  We must understand this XML syntax to know.

<item rdf:about="http://abc.com">
	<title>My title</title>
	<author rdf:about="http://www.joe.com/">
		<name>Joe</name>
	</author>
</item>

<colors rdf:about="http://abc.com">
	<text>blue</text>
	<background>white</text>
</colors>

Not being very familiar with RDF/XML, I have a nagging suspicion that 
I've done something wrong having the author right inside the item, but 
the point is that now we know that the author's <name> is referring to 
the author, and not the item, and that the <text> and <background> 
colors are referring to the item (or, more precisely, to the same thing 
that the item is referring to), because the rdf:about URI for <item> 
and <colors> is the same--they're talking about the same thing.

Does that capture a non-trivial part of what RDF gets us?  That we can 
tell exactly what each piece of data is talking about? And as more 
extensions are added to make places for more types of data within an 
Atom feed, however they may or may not be nested, we don't end up 
confused about what thing any particular piece of data is describing?

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 18 Aug 2004 08:35:40 -0700 (PDT)

> We're not talking AI here. Just data mixing and a

Before continuing, I'd like to note that besides
[perhaps] NewsMonster of the dozens of RSS aggregators
I have seen in action none treat extensibility in RSS
1.0 any different from extensibility in RSS 2.0. It's
all just XML and namespaces to them. The other
aggregator authors on the list can pipe up and
disagree with me if I am mistaken. 

Thus the claims of superiority of using RDF-based
extensibility in RSS 1.0 versus using XML + namespaces
as RSS 2.0 does have simply never been shown in the
wild besides the proof of concept stuff that the RDF
syndication usual suspects like Danny Ayers trot out
whenevr this discussion occurs. 

> (perhaps using the OWL extensions).

So far I haven't seen something which indicates a
better extensibility model when using RDF versus XML +
namespaces. It is more likely that an XML language
contains constructs that don't map to real world
constructs but instead are just there for markup
purposes but I see the same in RDF/XML as well with
all the sequences, lists and bags which don't even
occur in RSS 2.0 anyway. 

In fact one could argue that there is more of a 1:1
mapping between syndication construct in the typical
RSS 2.0 document than in an RSS 1.0 document
describing the same data. 

> conventions across otherwise indpendent

So far all you've done is assert that RDF based
extensibility is better without showing why in
concrete terms. I don't see why you claim it is so
hard to reuse an element from one schema in another,
it hapopens all the time in the world of RSS. Heck,
just a few days ago on this list we were discussing
using the dcterms:* elements in Atom without resorting
to using RDF-based extensibility, just XML and
namespaces. 

> namespaces make sense in the marketplace.

RSS 2.0 does all these and more today. It seems you
are either ignorant of what's happening in the
syndication space today or willfully ignoring the
current state of the syndication marketplace. 

> patterns you consider valid".

Reinventing the wheel is not necessarily a part of the
XML+namespaces approach. Weren't we all just
discussing Atom reusing the dcterms:* namespace
elements instead of reinventing similar concepts in
context of Atom? Similarly, can't I as easily come up
with my own RDF based syndication format that doesn't
use Dublin Core thus negating all the benefits you
claim one gets for free using RDF. 

It just seems you are advocating that vocabulary
designers not reinvent the wheel and reuse other
markup vocabularies where possible. Makes sense to me.

> at least merely very hard).

You've placed restrictions on the XML+namespaces route
that actually don't exist in practice as witnessed by
the number of RSS extensions as well as their support
by numerous clients. 

> structure around a lot of hard work.

Again, possible with RSS 2.0 using XML+namespaces
based extensibility. It happens all the time today as
it is. 
> come, then the "not our problem" approach to

Sure. I still await concrete, technical reasons
preferably with scenario-driven use cases or examples
that show how using RDF based extensibility somehow
buys one significantly more than using XML based
extensibility on a global, decentralized network like
the World Wide Web. 

=====

__________________________________
Do you Yahoo!?
Y! Messenger - Communicate in real time. Download now. 
http://messenger.yahoo.com

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 18 Aug 2004 08:46:00 -0700 (PDT)

> confused about what thing any particular piece of

There are several issues with your example. The first
is common to all of RDF, using URIs as identifiers is
ambiguous (another URI permathread coming up).  

If I use RDF:about="http://www.microsoft.com", am I
talking about the HTML retrieved by performing an HTTP
GET of that URL or the actual company Microsoft? Well,
it depends on context. If the tagname is <author> I'm
probably talking about the markup on the page but if
it is <ceo> I'm probably talking about the company.
This goes off into permathread land from here but this
example should get the point of why using URI as
identifiers is problematic in RDF. Since RDF isn't
used much outside closed environments or academic
circles you don't hear people complain about this
problem much. However if RDF ever gained traction on
the World Wide Web, this would be a significant
problem. 

Secondly, XML is all about hierarchies so I fail to
see why one would think that an element described its
sibling as opposed to its parent element in a markup
vocabulary. That is simply not idiomatic XML. 

=====

---

From: Ian Davis <[email-masked]>
Date: Wed, 18 Aug 2004 17:00:43 +0100

> whenevr this discussion occurs. 

I wonder how many RSS 2.0 extension modules are actually understood by 
RSS aggregators. How many does RSS Bandit support for example?

Ian

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 18 Aug 2004 09:10:08 -0700 (PDT)

> RSS aggregators. How many does RSS Bandit support
 
We support the following extension elements in an RSS
feed 

 - dc:date
 - dc:author
 - dc:description
 - dc:subject
 - content:encoded 
 - xhtml:body
 - slash:comments
 - wfw:comment
 - wfw:commentRss
 
There might be more but I'd have to look at the code
to be sure. 

=====

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 18 Aug 2004 17:26:30 +0100

Dare Obasanjo wrote:

> GET of that URL or the actual company Microsoft? 

Just how is this specific to URIs or RDF?

> identifiers is problematic in RDF. 

What identifiers would you suggest?

> Since RDF isn't

In no way is the significance of this problem restricted or specific 
to any technology mentioned in this thread. You argument is vapid.

cheers
Bill

---

From: Danny Ayers <[email-masked]>
Date: Wed, 18 Aug 2004 18:31:59 +0200

> identical - so RDF buys me nothing.

Dan and Bill showed the extensibility angle better than I, concentrating 
on the ability to mix stuff:

[[

The RDF approach isn't trying to make data universally understandable in
any fancy AI sense, just universally mixable. 
]]

But personally I think partial understanding is very cool indeed (but still not fancy ;-). You say the cost to support that kind of extension is identical for you. Ok, add another extension, and another and another. Without a common model you're looking at a cost comparable to the product of the number of extensions. With something above the syntax (even just a low-level entity/relationship model, like the core of RDF) you're looking at something more like a linear increase in cost.

Cheers,
Danny,

-- 

Raw
http://dannyayers.com

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 18 Aug 2004 10:09:49 -0700 (PDT)

> Just how is this specific to URIs or RDF?

URIs especially HTTP ones are ambiguous. RDF could
have come up with a mechanism where it used 1:1
mappings of concepts to identifiers instead of the
overloaded and muddy semantics of URIs. This isn't
rocket science. 
 
> What identifiers would you suggest?

I dunno, UUIDs or GUIDs for one. It's not like the
identifiers have to be human readable or directly
network retrievable. 

=====

---

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

> > RSS aggregators.

In addition to the above, Newzcrawler supports annotate:reference

At last count, Sharpreader, BottomFeeder, Newsmonster, and WinRSS all
support the inclusion of Atom's core elements within RSS via namespaces...
atom:content, for example.

And according to their marketing materials, Newsgator supports arbitrary
extensions as viewable/sortable fields.

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 18 Aug 2004 11:09:26 -0700 (PDT)

> In addition to the above, Newzcrawler supports

I've been looking for an RSS module for representing
USENET posts in feeds. Looks like I found one. RSS
Bandit will definitely support this in the next
version. 

Sweet. 
 
> atom:content, for example.

You mean they allow arbitrarily mixing different XML
vocabularies that were designed in isolation without
them having to use RDF? Say it ain't so. :) 

> extensions as viewable/sortable fields.

Although it sounds cool I wonder how many of their
users have actually found this functionality useful or
used it at all. 

=====

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 18 Aug 2004 19:12:30 +0100

> identifiers have to be human readable or directly

My point, and I'm not trying to shift the argument towards useless 
abstractions, is that ambiguity is an issue that transcends choice 
of identity schemes or models - it's one of those things you learn 
to put up with it, sort of like latency. Granted inserting further 
ambiguity a la http: URLs is dubious engineering. But it won't work 
to suggest if we stop doing that that ambiguity disappears in a puff 
of logic. For example, I can search replace URI with GUID in the RDF 
model theory and not alter its semantics, but the scope for 
ambiguity remains.

Here's something I do agree with: for the blogger/aggregator use 
cases XML+Namespaces plus whatever extensibility recommendations we 
can take from you or Norm's or Dave's thoughts ought to be 
sufficient. In reality, unless someone embeds an RDF backed 
inferencing engine in an /aggregator/, it's all switch blocks and 
hash maps; RDF won't be leveraged. This is like saying passing 
relational tables into C# code doesn't mean SQL will get leveraged, 
iterators will. It's where Atom is taken beyond those use-cases 
there may be issues; i.e. where people want to be able to reuse atom 
constructs in such an inferencing context, but it's not clear to me 
we are 'chartered' for that concern.

As for James Robertson's point. If we were sharing smalltalk objects 
I guess we'd be sorted :) In the meantime I'm not sure how I or your 
run of the mill DPH can interoperate with or leverage his seemingly 
excellent object model. So I suppose we need to figure out something 
for the markup.

cheers
Bill

---

From: Mark Pilgrim <[email-masked]>
Date: Wed, 18 Aug 2004 14:15:31 -0400

> > > I wonder how many RSS 2.0 extension modules are

http://feedparser.org/docs/reference-entry-modified_parsed.html

> >  - dc:author

http://feedparser.org/docs/reference-entry-author_detail.html

> >  - dc:description

http://feedparser.org/docs/reference-entry-summary_detail.html

> >  - dc:subject

http://feedparser.org/docs/reference-entry-categories.html

> >  - xhtml:body

http://feedparser.org/docs/reference-entry-content.html

> >  - wfw:commentRss

These are qname-normalized to their defacto "standard" prefix and
their values returned as-is:

http://feedparser.org/docs/namespace-handling.html

-- 
Cheers,
-Mark

---

From: Sam Ruby <[email-masked]>
Date: Wed, 18 Aug 2004 14:30:37 -0400

> We support the following extension elements in an RSS

And admin:errorReportsTo... per 
http://www.intertwingly.net/blog/2004/04/29/Feedback-loops#c1083248806

- Sam Ruby

---

From: Ian Davis <[email-masked]>
Date: Wed, 18 Aug 2004 20:29:01 +0100

> There might be more but I'd have to look at the code
Anything more complex than single elements e.g. threading or embedded 
creative commons licenses?

If so, how many lines of code does the parsing of those extensions take?

Ian

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 18 Aug 2004 12:38:31 -0700 (PDT)

> creative commons licenses?

I'm not sure what is meant by this question. Are you
asking if I support any elements that are have complex
content (attributes + child elements) as extensions?
If so the answer is no. 

> If so, how many lines of code does the parsing of

Parsing out the content of the element based on its
name takes the same 4 - 8 lines of code. However what
ends up being done with the extension varies very
wildly. The code to retrieve the comment RSS feed is a
lot more complex than that to display the dc:subject
value of an item for example. I'm not sure what kind
of reasonable comparison can be made here. 

=====

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

---

From: Ian Davis <[email-masked]>
Date: Wed, 18 Aug 2004 20:58:55 +0100

> content (attributes + child elements) as extensions?

I think there's a complexity difference between single element 
extensions that appear as children of the primary elements (e.g. 
channel/item/feed/entry) and complex structures such as creative commons 
where you may want to embed a description of a custom license.

Parsing the former is just a few lines of code, the latter may add much 
more complexity since you need to store parent element context as you 
descend the markup tree. I'm not talking about implementing the effects 
of the extension - obviously that differs widely depending on the semantics.

Adopting a standard syntactical structure for extension modules means 
readers can have one standard parsing component that can parse Atom plus 
any combination of extensions into a queryable data model.

Ian

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 18 Aug 2004 13:42:55 -0700 (PDT)

> depending on the semantics.

You are assuming all sorts of things about what the
implementation does. For example, a DOM based
implementation wouldn't have these issues you claim.
And in fact, all versions of RSS Bandit have used a
DOM for parsing XML and I recently changed this just a
few weeks but haven't shipped this change in a release
yet. 

> any combination of extensions into a queryable data

The way the RSS Bandit code is written it doesn't
matter if unknown extensions are simple or complex
content. So I wouldn't benefit from or be harmed by a
decision such as this. I personally find it
unnecessarily limiting just to potentially save a few
lines of fairly straightforward code in aggregators. 

=====

---

From: Ian Davis <[email-masked]>
Date: Wed, 18 Aug 2004 21:50:17 +0100

> lines of fairly straightforward code in aggregators. 

Fair enough. I, personally, would prefer not to have to write new 
parsing code with associated data structure every time I want to support 
a new extension. I'd rather focus on the extension behaviour than its 
syntax.

Ian

---

From: Robert Sayre <[email-masked]>
Date: Wed, 18 Aug 2004 16:52:21 -0400

> where you may want to embed a description of a custom license.

If a given structure is really complex, it probably doesn't belong in a 
syndication feed as metadata. A reference to an external resource would 
be fine [0]. If you really want to include it, there's nothing stopping 
you from using an extension consisting of RDF/XML.

There are a limited number of subjects in an Atom Entry. A 
general-purpose model like RDF seems like total overkill to me. However, 
that's just opinion. We're here to standardize current practice, so 
let's see some examples of complex RDF extensions succeeding in 
syndication. For example, how widely used is the "rich" variant of the 
RSS1.0 DC module?

Robert Sayre

[0] http://backend.userland.com/discuss/msgReader$200

---

From: James Robertson <[email-masked]>
Date: Wed, 18 Aug 2004 22:15:54 -0400

BottomFeeder handles 15 of them at the moment

>I wonder how many RSS 2.0 extension modules are actually understood by RSS 
>aggregators. How many does RSS Bandit support for example?
>
>Ian
>
>

---

From: Danny Ayers <[email-masked]>
Date: Thu, 19 Aug 2004 10:12:52 +0200

In the same way that XML plus namespaces can keep terms separate at a 
syntax level without prior agreement between developers, the RDF model 
can keep terms separate at a logical level. Both are necessary to avoid 
interrnal conflict in applications. Without a similar mechanism (it 
could be considerably simpler) Atom will have to be very limited in 
terms of extensibility, or it won't scale.

>whenevr this discussion occurs. 

It's true that most popular aggregators don't support a wide range of 
extensions, but that is about implementation, not language design. As to 
their existence in the wild, the are *lots* of RDF stores around, all of 
which can consume RSS 1.0 based syndicated material. RSS aggregators are 
generally, by design, single-purpose applications for reading news-like 
feeds.

Just for the record, here are a couple of RDF-based systems that had 
specific support for RSS material (there are more, I just don't have a 
list at hand):
Intellidimension's Desktop Portal
http://www.intellidimension.com/pages/site/packages/pportal/default.rsp
(the same kit, RDF Gateway, is used in their search engine:
http://www.semanticwebsearch.com/)

Knobot:
http://sourceforge.net/projects/knobot/

>it hapopens all the time in the world of RSS. 
>
Do you remember the fun surrounding the inclusion of xhtml:body in RSS 
2.0 feeds?

>Heck,

I don't think anyone's expecting Atom to use RDF-based extensibility, 
merely stating that RDF/XML approach has considerable advantages over 
XML plus namespaces alone. I would hope Atom will be able to support 
dcterms, but this will be fragile unless there is some kind of mandated 
use of these specific terms, or a more general purpose extensibility 
that allows namespace mixing in a general fashion.

>current state of the syndication marketplace. 

No it doesn't.

>markup vocabularies where possible. Makes sense to me.

For sure, but to be able to reuse those vocabularies it is necessary to 
consider how they may interact.

>extensibility on a global, decentralized network like

The concrete technical reason is that RDF-based extensibility 
ring-fences the terms through the data model expressed through RDF/XML 
syntax. There is nothing to define how individual XML-only terms work 
with core syndication terms, let alone each other. Unless you get every 
designer to agree with every other designer on specific interactions.

I pasted this to the top as summation: In the same way that XML plus 
namespaces can keep terms separate at a syntax level without prior 
agreement between developers, the RDF model can keep terms separate at a 
logical level. Both are necessary to avoid interrnal conflict in 
applications. Without a similar mechanism (it could be considerably 
simpler) Atom will have to be very limited in terms of extensibility, or 
it won't scale.

Cheers,
Danny.

-- 

Raw
http://dannyayers.com

---

From: Danny Ayers <[email-masked]>
Date: Thu, 19 Aug 2004 10:56:36 +0200

Dare Obasanjo wrote:

>For example, a DOM based

Ok, so you're acknowledging the use of a model can be helpful in 
managing extensions. The DOM model provides a hierachical data model, 
whereas the RDF model can be seen in terms of a graph or a set of 
statements (triples). Perhaps somewhere between the two lies something 
useable in Atom.

Why not just simple striping:

<entityA>
   <relationship>
                 <entityB>
    </relationship>
</entityA>

Nested as much as needed, but always following the 
entity-relationship-entity-relationship-entity pattern. This would 
considerably disambiguate terms at the logical level, without 
introducing any of the kind of syntactic variation possible in RDF/XML.

(entityB may alternately be a text node)

e.g.

<entry>
    <title>The Title</title>
</entry>

Ok, we know that one, but:

<entry>
     <x:qwe>Something</x:qwe>
</entry>

States that entry has a characteristic called x:qwe with the value 
"Something".

The current Atom syntax is very close to this already, the only 
exceptions I think being author/contributor which munges the entity with 
the relationship.
      
Cheers,
Danny.

-- 

Raw
http://dannyayers.com