Subject: RE: PaceMinimalVersioning

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

> -----Original Message-----
> From: [email-masked] [mailto:owner-atom-
> [email-masked]] On Behalf Of Tim Bray

<snip/>

> > 2.) Your Pace implies that if a required element is
> > ever added in a future version of Atom it will have to
> > appear with atom:must-understand="true". Is this
> > intentional?
> 
> Yes.  This seems fail-safe and furthermore has the desirable effect of
> discouraging the addition of required future elements.

-1.  Yucko.  Every single required addition having an mU is overly
complicated.

> 
> > 3.) Unrecognized attributes are always ignored. So
> > this means any attributes added to core elements must
> > be optional. Is this also intentional?
> 
> Right.  I don't see any way around it.

For a given "major" version, I can't see any other way 
> 
> > If you want to create a true PaceMinimalVersioning I'd
> > eschew all the MustUnderstand crud and just state
> >
> > (i) Unknown elements and attributes can always be
> > ignored
> > (ii) Version number is split into major/minor version.
> > Atom is backwards compatible between minor versions.
> > So Atom 1.0 & Atom 1.1 are compatible but Atom 1.0 &
> > Atom 2.0 are not.
> 
> I find the term "backwards compatible" horribly underspecified.  I
want
> a deterministic, simple set of rules that specify what software can
and
> can't be relied upon to do in the face of unrecognized and erroneous
> markup.  I claim that PaceMinimalVersioning provides that.  If you can
> translate the term "backwards compatible" into a set of RFC2119-style
> constraints we could compare them easily with PaceMinimalVersioning.
> -Tim

Here's a definition for backwards compatible:
http://www.w3.org/2001/tag/doc/versioning#dt-backwards-compatible.
PaceExtensibilityAndVersioning provides the 2119-style constraints to
achieve it.

Dave