Subject: RE: Extensbility and Versioning Paces

From: "David Orchard" <[email-masked]>
Date: Thu, 16 Sep 2004 10:24:21 -0700

> -----Original Message-----
> From: Dare Obasanjo [mailto:[email-masked]]
> Sent: Wednesday, September 15, 2004 3:12 PM
> To: David Orchard; Atom-Syntax
> Subject: RE: Extensbility and Versioning Paces
> 
> 
> --- David Orchard <[email-masked]> wrote:
> >
> > We're agreed that Atom 1.1 would be backwards
> > compatible with Atom 1.0.
> > So why would a human want to look at the 1.0 wrt the
> > site?  The site
> > doesn't care about Atom 1.0 any more, it's moved to
> > 1.1.
> 
> *sigh*

Thanks for being patient; I'm really trying to understand the scenarios.
I understand now that there are 2 scenarios: Figuring out the version of
atom the site supports and figuring out the definition of an optional
element.

> 
> If there is no version number how do you know what
> version of Atom the site supports. When I first
> started implementing RSS Bandit I did so by looking at
> the feeds of various sites I wanted to be able to read
> then going to the spec for the version of RSS they
> supported.

So the version # actually indicates a version of the site rather than an
individual feed.  Seems like mixing 2 things together, there's the
version of the instance of the feed and then there's the version of the
feed that the site supports.  Kind of the way that HTML over HTTP
messages have an HTTP version # and an HTML version #.  

Presumably a site could support multiple versions of RSS as well, and
this wouldn't cover that.  A site could say "I support Atom V1.0 and
Atom V2.0", but the version attribute wouldn't cover that scenario.

In both cases - version #s or no version #s - you have to look something
up.  I'm arguing that you can use the namespace name just fine for
looking up the RSS information.  In fact, I'd suggest that the atom
namespace should be dereferencable to a RDDL document, but that's a
separate idea.

I say you can use the namespace name for figuring out the "version".  If
it's V2.0 site, then you can use the Atom V2.0 namespace name.

> 
> If there is no version number in the feed how do I
> tell which version of atom
> <atom:some-optional-element> is defined?

The "latest" version of the atom spec will always have the definition of
"some-optional-element".  

In my view, you want the version attribute to look up a spec to figure
out what the optional element is.  So just look up the atom spec and see
the definition of the optional element.  

Let's compare the 2 mechanisms in a scenario.

No version #s: you understand atom namespace but not
atom:some-optional-element.  You get an atom:some-optional-element.
Your software works.  You notice that some-optional-element is showing
up.  You look up the definition of some-optional-element in the atom
spec that you got from the atom ns.

Version #s: you understand atom namespace and version #V but not version
#V+1.  You get a feed with a version #V+1 and an
atom:some-optional-element.  Your software works.  You notice that #V+1
and an atom:some-optional-element are showing up.  You look up the
definition of #V+1 and find some-optional-element in the atom spec that
you got from the atom ns.  

In both cases, you look up the atom spec for the definition of
some-optional-element.

The only rationale that I've heard so far for the version attribute is
so that you can see earlier in the feed that atom has added an optional
element that you might be interested in.  It doesn't help for looking up
the definition of the optional element.  And it doesn't help for 3rd
party extensions.  

> 
> > Say something optional has been added.  Then the 1.1
> > site now knows
> > about the optional thing.  From the clients
> > perspective, there's nothing
> > different between something optional in v1.0 and
> > something optional
> > added into v1.1.  It can ignore the v1.0 and the
> > v1.1 optional thing.
> 
> I know that I said as much in my mail you are
> responding to.

I am highlighting the fact that the client sees no difference between an
optional thing in v1.0 and an optional thing added to make v1.1.  The
client does not need to distinguish between which "version" contains the
optional thing. 

<snip/>
> 
> > A scenario I was thinking of was say a site will
> > return an image in v1.1
> > and not in v1.0 for whatever request.  If the site
> > knows the client is
> > v1.0 then it could know to not return the image
> > (even though the image
> > will be safely ignored by the client) for
> > performance reasons.
> 
> I don't think this is mainstream scenario.
> 

OK, I was just trying to come up with a scenario, but I'll drop it and
focus on your 2 scenarios.

Cheers,
Dave

---

From: Eric Scheid <[email-masked]>
Date: Fri, 17 Sep 2004 07:13:43 +1000

> In both cases, you look up the atom spec for the definition of

This assumes that the definition of some-optional-element doesn't get
refined, clarified, expanded or otherwise tweaked in successive versions of
the spec texts. Sure, it's mostly a safe bet because of the process we're
going through here, but there's no guarantee.

e.