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 PROTECTED] [mailto:owner-atom- > [EMAIL PROTECTED] 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 PROTECTED]> 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
