Antone Roundy wrote:


On Thursday, February 3, 2005, at 02:18 PM, Norman Walsh wrote:

- 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.

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?

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




Reply via email to