Subject: PaceRemoveVersionAttr

From: Norman Walsh <[email-masked]>
Date: Thu, 03 Feb 2005 16:18:44 -0500

Some thoughts

- It seems very likely to me that Atom will evolve over time.

- For some applications, changing the namespace name with every
  version is entirely impractical. Atom may or may not be in this
  category. Do feeds become legacy? Are people storing entries with
  the expectation that the readers of 2014 will be able to display
  them, albeit perhaps imperfectly? Changing the namespace makes that
  *hard*. XSLT transformations and XML Queries for Namespace1 flatly
  will not work with Namespace2.

- When I look at a feed, I am comforted on some emotional level by my
  ability to know what version the creator intended it to be.

- Perhaps YAGNI applies.

I think, on balance, I'm +1 for keeping it, but I doubt I'd lie down
in the road over it.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Life is a great bundle of little
http://nwalsh.com/            | things.--Oliver Wendell Holmes

---

From: Graham <[email-masked]>
Date: Thu, 3 Feb 2005 21:36:11 +0000

> I think, on balance, I'm +1 for keeping it, but I doubt I'd lie down

Yes. I like it too.

Graham

---

From: Antone Roundy <[email-masked]>
Date: Thu, 3 Feb 2005 15:11:04 -0700

>   ability to know what version the creator intended it to be.

I used to be fairly attached to being able to see a version number in 
the feed, but no longer am, IF the following conditions are met.  In 
the following, b > a and X != Y--the rest is indeterminate:

1) A valid Atom X.a feed is guaranteed to be a valid Atom X.b feed

2) An application aware of Atom X.a can safely ignore changes made in 
Atom X.b

3) The namespace for Atom version X.a is guaranteed to be the same as 
for Atom version X.b

4) The namespace for Atom version X.a is guaranteed to be different 
than the namespace for Atom version Y.c

5) X can easily be determined by viewing the namespace for Atom version 
X.*

I think this is what we're aiming for, but I'm not certain that we have 
approved spec text to ensure it.  PaceExtendingAtom addresses some of 
this, but not all of it.  Do we need something more?

---

From: Sam Ruby <[email-masked]>
Date: Thu, 03 Feb 2005 19:56:32 -0500

>   ability to know what version the creator intended it to be.

For me, I'd like the comfort of knowing that a V1.0 feed will continue 
to be valid with respect to future versions of the specifications, and 
that tools written to consume V1.0 feeds will continue to work with 
subsequent versions of the specification.

RSS 0.9x (including 2.0) is evidence that the former is possible (I can 
cite some minor incompatibilities, but these are merely exceptions that 
prove the rule).  I do believe that the latter is also possible.

Without ever changing the namespace.

- Sam Ruby

---

From: Sam Ruby <[email-masked]>
Date: Thu, 03 Feb 2005 20:00:03 -0500

Antone Roundy wrote:

> the feed, but no longer am, IF the following conditions are met.  In the 
> following, b > a and X != Y--the rest is indeterminate:
> 
> 4) The namespace for Atom version X.a is guaranteed to be different than 
> the namespace for Atom version Y.c
> 
> 5) X can easily be determined by viewing the namespace for Atom version X.*
> 

That is what I am aiming for.

I put some placeholder text at the bottom of PaceRemoveVersionAttr, but 
it definately needs to be expanded/improved.

- Sam Ruby

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 3 Feb 2005 20:27:34 -0800

In its present form, I want to get rid of the version attribute. That's 
not to say that I don't want something with more useful semantics, on a 
separate axis from the namespace.

So, +1 to the Pace.

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

---

From: Joe Gregorio <[email-masked]>
Date: Fri, 4 Feb 2005 17:36:03 -0500

> Without ever changing the namespace.

+1

And +1 to PaceRemoveVersionAttr, particularly in light
of Atom being a Must Understand vocabulary.

-- 
Joe Gregorio        http://bitworking.org

---

From: Graham <[email-masked]>
Date: Sat, 5 Feb 2005 01:16:17 +0000

>> I think, on balance, I'm +1 for keeping it, but I doubt I'd lie down

Just to clarify, I like it being there for 
informational/statistics/debugging purposes. I don't see what harm it 
causes or why there's any need to remove it.

Graham