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

[Joe Cheng <Joe.Cheng@xxxxxxxxxxxxx>]

Having had lunch, I withdraw this message. I didn't mean to
advocate further for booleans, which is what I ended up doing.
Status is fine, and I don't care if "prohibited" is in there or
not (if so, I'd probably treat it the same as "unsupported" but
it wouldn't bother me to have to do so).

-----Original Message-----
From: owner-atom-protocol@xxxxxxxxxxxx [mailto:owner-atom-protocol@xxxxxxxxxxxx] On Behalf Of Joe Cheng
Sent: Friday, August 17, 2007 12:47 PM
To: A. Pagaltzis; atom-protocol@xxxxxxx
Subject: RE: Judging consensus for publishing Atompub-features on Standards Track


A. Pagaltzis wrote:
> Specifying a behaviour for unknown new values on a particular
> known attribute seems a far more tractable issue to me. I think
> the right thing to do in that case would be for the client to
> simply ignore such a `feature` element; assuming “unsupported”
> would be limiting, while assuming “supported” is unwarranted.
> The most sensible behaviour seems to be that the client should
> just fall back on its default assumptions.

Try looking at it from this point of view. You're a server
implementer with thousands of end-users, with many of them
happily using Windows Live Writer and MarsEdit to edit their
blogs. A new status is introduced (say we didn't have
"prohibited" and now we do). 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).

With booleans, you at least have the ability to know what set
of booleans a legacy client should know about, and tailor
those appropriately. It may not be as elegant, but as I always
say, "My users don't care about that." :) (Now, you can also
do this with status by adding a status2 and telling new clients
to look there and ignore status if it's present. But if you
don't like booleans then I imagine you must REALLY hate that
idea!)

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. How about
this. 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.