Subject: RE: Is Atom 0.3 Actually Atom 1.0?

From: "David Orchard" <[email-masked]>
Date: Thu, 16 Sep 2004 12:00:31 -0700

> -----Original Message-----
> From: [email-masked] [mailto:owner-atom-
> [email-masked]] On Behalf Of Tim Bray
> Sent: Thursday, September 16, 2004 11:55 AM
> To: Mark Baker
> Cc: Bjoern Hoehrmann; [email-masked]
> Subject: Re: Is Atom 0.3 Actually Atom 1.0?
> 
> 
> On Sep 16, 2004, at 10:39 AM, Mark Baker wrote:
> 
> > Atom 0.3 and Atom 1.0 are incompatible specifications.  They might
as
> > well be called Joe and Bob.  That alone should be sufficient grounds
to
> > require different media types, IMO.  Yes, it's unfortunate that 0.3
got
> > there first and staked claim to the canonical and easy-to-remember
> > "atom+xml" subtype, but such is life.
> 
> I think it's too late.  I did some lobbying and got the Apache and IIS
> people to agree to use "application/atom+xml" by default for the
> extension ".atom"; Apache is already shipping.  So receiving software
> is just gonna have to look at the "version=" attribute.  But it would
> have to anyhow.  No biggie. -Tim

Or look at the namespace name of the feed element.

Dave

---

From: Sam Ruby <[email-masked]>
Date: Thu, 16 Sep 2004 15:55:15 -0400

> Or look at the namespace name of the feed element.

Or look for the /absense/ of a version attribute.

I've always liked the YAGNI[1] argument for version numbers.  Let's add 
it in the first release which requires such a thing.  And work really 
hard to avoid ever needing it.

- Sam Ruby

[1] http://c2.com/cgi/wiki?YouArentGonnaNeedIt

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 16 Sep 2004 15:57:18 -0700 (PDT)

--- Mark Baker <[email-masked]> wrote:
> 
> Erm, no.  Namespaces make for a pretty sucky
> application dispatch
> mechanism because they're intrinsic to the data
> rather than extrinsic
> to it.  That reasoning is what lead to the use of
> the */xml types for
> a whole lot of XML based formats, which folks are
> finally realizing was
> a bad idea.

As much as you think namespaces suck as a dispatch
mechanism, at least they are used unlike MIME types
which are generally ignored on the Web. 

> But I agree with Tim, this isn't a biggie.  To me
> it's just one of those
> little things that is easy to get wrong, and always
> comes back to haunt
> you in some way in the future.  If the group can't
> see that, that's
> unfortunate, but I'm not going to lose any sleep
> over it. 8-)

Thanks for not ratholing on this issue. 

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

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

---

From: Mark Baker <[email-masked]>
Date: Thu, 16 Sep 2004 15:49:46 -0400

> Or look at the namespace name of the feed element.

Erm, no.  Namespaces make for a pretty sucky application dispatch
mechanism because they're intrinsic to the data rather than extrinsic
to it.  That reasoning is what lead to the use of the */xml types for
a whole lot of XML based formats, which folks are finally realizing was
a bad idea.

But I agree with Tim, this isn't a biggie.  To me it's just one of those
little things that is easy to get wrong, and always comes back to haunt
you in some way in the future.  If the group can't see that, that's
unfortunate, but I'm not going to lose any sleep over it. 8-)

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

---

From: Danny Ayers <[email-masked]>
Date: Sat, 18 Sep 2004 19:28:24 +0200

> Or look for the /absense/ of a version attribute.

I like it.

> hard to avoid ever needing it.

"Always implement things when you actually need them, never when you
just foresee that you need them."

I'm not sure spec authors have the same luxury of YAGNI that coalface
coders have, or at least won't have until versioning specs is as
simple (!) as versioning software.

# apt-get global-deployment-upgrade
Reading Package Lists... Done
Building Dependency Tree... Done
Calculating Upgrade... Done
The following specification will be REMOVED:
 atom2.0
The following NEW specifications will be installed:
 atom2.1
The following packages have been kept back
 cdf rss0.9 rss1.0 rss0.91n rss0.91u rss0.92 rss0.93 rss0.94 rss2.0
rss2.01 rss3.0
0 packages upgraded, 1 newly installed, 1 to remove and 9 not upgraded.
Do you want to continue? [Y/n]

Do we foresee needing a version number? Not in the near future at least.

Cheers,
Danny.

-- 

http://dannyayers.com