Subject: RE: Extensbility and Versioning Paces

From: "David Orchard" <[email-masked]>
Date: Wed, 15 Sep 2004 07:36:31 -0700

> -----Original Message-----
> From: Dare Obasanjo [mailto:[email-masked]]
<snip/>

> > A couple questions on delineation:
> > 1) If Atom creates a backwards compatible extension
> > and creates a new
> > namespace for these extensions but does not update
> > the "atom schema" is
> > this extensibility or is this versioning?
> 
> You have loaded the question by calling them
> 'extensions'. The question is if v2.0 of Atom creates
> new optional elements but puts them in a different
> namespace, is that extensibility or versioning?
> 

Fair enough, sorry about that.  I am trying to understand your view of
the difference between extensibility and versioning.

> If they are optional then there is no difference
> between them and extension elements so I don't think
> the answer to the question matters much except as a
> philosophical discussion.
> 

So you don't differentiate between extensions and versions for
compatible changes by the namespace owner even if they use a new
namespace for the addition.  An optional element addition is either
extension or versioning when done by ns owner.  If a 3rd party does the
optional addition, then that is presumably extension.  From a clients
perspective, they might guess that an additional element is an extension
vs a version change by knowing the namespace name domain owner, but they
don't know for sure.

Follow on questions:
1) If Atom creates an incompatible addition to V1.0 and does this in a
new namespace that is clearly a new version.  Is it also an extension?
2) If a 3rd party creates a compatible addition (presumably an
extension) and then Atom references it, do you have the same view that
there is no difference between extension and versioning?

> 
> 
> > 2) What about case #1 where the "atom schema" is
> > updated with the new
> > qnames?
> >
> > I think that in the difference between extensibility
> > and versioning in
> > the face of multiple namespaces being used by the
> > spec owner is very
> > fuzzy.  Is this why some folks seem to be in favour
> > of version numbers?
> 
> Version numbers provide a way to identify versions of
> the format without resorting to changing namespace
> names. The alternative is processing the document
> until seeing some unknown but required element,
> attribute or enumeration value. The process for
> determinging whether an Atom feed can be consumed by a
> client should be a simple check not read the entire
> file until you see something weird. What if the weird
> thing only shows up every couple of days in the feed?
> 

That's not a reasonable argument from the atom versioning perspective.
It isn't either: version #s or parse entire document.  It's either:
version #s or change qname.  If the atom community makes an incompatible
change, it can change the feed qname to identify that there is a change
and a full parse is not necessary.  If a 3rd party puts in a mandatory
extension, then they do not have the authority to change the version #
or the feed qname.  They would mark the extension with mustUnderstand so
the software will have to process the entire feed for mustUnderstand.  

In both cases - atom makes an incompatible change or 3rd party adds
mandatory extension - the version attribute is unnecessary compared to
namespaces for indicating incompatibility.  One reason why I don't
believe version attributes should be used for major or incompatible
versions.

If you want to avoid a complete parse of the document for mandatory 3rd
party extensions, then version #s aren't the solution.  One solution is
to do a "manifest" of mandatory extensions earlier in the tree, ie a
atom:mandatoryExtensions="myns yourns".

> Given the above statement I definitely think the text
> in section 7.2
> 
> "Any future version of Atom that is incompatible with
> this version will either use a different namespace
> name or will use an element name not defined in this
> specification. An example is adding a required
> element/attribute or removing an element or
> attribute."
> 
> should be tightened up. I don't think it should be an
> either or situation. Backwards incompatible versions
> must provide an explicit mechanism for stating they
> are incompatible, clients shouldn't have to process
> the entire message looking for stuff that they don't
> understand.

I agree with explicit mechanisms for identifying incompatible versions
of atom.  I agree that clients should not have to process the entire
document to detect incompatible atom changes.  I assert that using a new
qname for feed (atom:feed) by either: 1) namespace name for
feed(atomnew:feed) OR 2) same namespace + new name for feed (ie
atom:feedNEW).  These indicate that the feed is incompatible with older
atom:feed as the client can just look at the root component.

Cheers,
Dave

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 15 Sep 2004 12:11:35 -0700 (PDT)

> the software will have to process the entire feed

You are right. I didn't think that part through. 
 
> believe version attributes should be used for major

The bottom line of my argument is that if the same
namespace name is used for different versions of the
format then how do I identify which version a
publisher is using? 

If I go to some site that uses Atom 1.1 instead of
Atom 1.0 and the namespace name doesn't change how can
I tell? It's fine and dandy that an aggregator will
ignore any added optional elements between versions
but what about humans reading the feed that want to
know what spec defines the elements and attributes in
the feed? Will the namespace name point to network
retrievable resource that lists the various versions
of Atom then the user has to play hide and seek trying
to figure out which one applies to the feed he just
saw? 

=====
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: Dare Obasanjo <[email-masked]>
Date: Wed, 15 Sep 2004 12:18:20 -0700 (PDT)

> new namespace that is clearly a new version.  Is it

To humans it is part of a new version of Atom. To Atom
clients it is a mandatory extension.

> there is no difference between extension and

The situation in (1) is the same as this to me. 

=====

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