Re: Judging consensus for publishing Atompub-features on Standards Track

["A. Pagaltzis" <pagaltzis@xxxxxx>]

* Joe Cheng <Joe.Cheng@xxxxxxxxxxxxx> [2007-08-17 22:00]:
> If you want to use the new status, you're now making the
> behavior for existing clients undefined (unless you've gone and
> tested every client your end-users are using, if you even know
> what those clients are).

No, existing clients should simply ignore features listed with a
status that the client in question does not understand. That’s no
more undefined than clients ignoring foreign markup in Atom feed
documents.

> I agree though that it's distasteful that booleans can
> contradict each other, and as you have more and more non-
> orthogonal booleans that might become intractable.

It’s not just distasteful; it’s gonna be a source of headaches
and real bugs.

Derek Denny-Brown wrote a nice post about this a year ago:

    Beware Bags of Bools
    http://nothing-more.blogspot.com/2006/04/beware-bags-of-bools.html

> Rather than one status, you can provide multiple; the first one
> that's understood by the client will be respected, and if none
> are understood, then the client can do whatever. Similar to how
> you specify fonts in CSS.
> 
> Is that just crazy overdesign? I'm kind of ambivalent about it.

I think it is.

We’ve had this discussion in the WG before: the problem you are
talking about is exactly the same as versioning the Atom format
proper. The answer is likewise exactly the same as for versioning
the Atom format proper: clients should default to ignoring things
they don’t understand, and if you need to introduce new semantics
that old clients cannot simply ignore (which would hopefully
never happen) then you rev the namespace.

Yes, that excludes old clients – but that is the point. After
all, they have no chance of doing something sensible anyway. If
there is something useful they can do, you can add appropriate
elements from the old namespace to inform them. This is basically
like your suggestion to use `status2`, only on a bigger scale –
and without any need to put verbiage in the spec up front. (The
verbiage in the superseding spec ends up shorter too.)

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>