Subject: RE: Published extensibility Paces

From: "David Orchard" <[email-masked]>
Date: Thu, 11 Nov 2004 10:05:08 -0800

A reason why I'm a fan of the mustUnderstand rule is that it enables
parties to make incompatible changes, in some situations considered a
"major" revision.

Without an mU rule, the only way that incompatible changes can be made
is through a revision of the Atom namespace and/or version, depending on
how we decide to do component version identification.

Another way of looking at this is that if you don't really want an Atom
NG format, then mU is a way of allowing new "versions" to exist.  

Here's a couple opposite scenarios for you:
1. Atom does not have mU.  Somebody comes up with a really really good
mandatory extension.  The only way to get this feature in is to Rev Atom
to Atom next namespace (or V 2.0)
2. Atom has mU.  Nobody in the entire community comes up with a really
really good mandatory extension.  Nobody uses mU and Atom
namespace/version also never gets created.

Seems like the safe place to be is to have mU, because without it you
are taking a gamble you don't need to.  And if you are right that nobody
will use mU, then there won't be any complications in atom format
instances because, well, nobody will use it..  

I agree that spending time/effort on something that might not get used
seems like craziness, but the problem is that it's impossible to predict
the future, even as smart as all the Atom folks are.  Previous versions
of RSS seem to validate my belief about being cautious on our
omniscience.

Cheers,
Dave

> -----Original Message-----
> From: [email-masked] [mailto:owner-atom-
> [email-masked]] On Behalf Of Joe Gregorio
> Sent: Wednesday, November 10, 2004 7:48 PM
> To: Tim Bray
> Cc: Atom WG
> Subject: Re: Published extensibility Paces
> 
> 
> On Wed, 10 Nov 2004 15:04:47 -0800, Tim Bray <[email-masked]> wrote:
> >
> > I had a talk about Atom and extensibility with Dave Orchard this
> > morning, and he convinced me that there is benefit in a
must-understand
> > facility, but then educated me as to how complex it can be to
> > implement.
> >
> > Based on that discussion, I have just published
> > PaceMustUnderstandElement and PaceExtendingAtom.  Note that the WG
> > could reject PaceMustUnderstandElement and I think that
> > PaceExtendingAtom would still work.
> 
> -1 on PaceMustUnderstandElement, for the following reasons:
> 
> 1. There is a mustUnderstand feature in SOAP and has proved of no
value.
>     You may attribute that to there being very few compliant
> implementations
>      in SOAP, but that only leads me to my next point:
> 2. This is added complexity to the format that few, if any, developers
> will implement.
>     As you report Dave Orchard said, this is complex to implement.
> 3. The Pace, as written, doesn't specify any concrete benefit. There
is
>    only theoretical benefit. What situation, current or in the past,
in
>    syndication formats, would a mustUnderstand element have helped?
> 
>     -joe
> 
> --
> Joe Gregorio        http://bitworking.org

---

From: Joe Gregorio <[email-masked]>
Date: Thu, 11 Nov 2004 13:31:15 -0500

> to Atom next namespace (or V 2.0)

For the addition of a new *mandatory* extension I think
a version 2.0 is a perfectly reasonable solution.

> namespace/version also never gets created.

Yet a lot of software on the client side gets written to support
such a change. That's not much of a feature/benefit trade off.

> the future, even as smart as all the Atom folks are. 

Sure, and if we run into a problem we get all these smart
people back together to produce a 2.0 spec.

>  Previous versions

Gettting back to that point about RSS, and to repeat one of my 
questions: Can you present a single instance in the history
of RSS (any version) where a problem occured that could have been fixed
with a mustUnderstand element?

    Thanks,
    -joe