W3C home > Mailing lists > Public > public-i18n-its@w3.org > July to September 2006

Re: AW: Features at risk

From: Martin Duerst <duerst@it.aoyama.ac.jp>
Date: Tue, 26 Sep 2006 10:31:48 +0900
Message-Id: <>
To: Felix Sasaki <fsasaki@w3.org>, "Lieske, Christian" <christian.lieske@sap.com>
Cc: public-i18n-its@w3.org

At 18:29 06/09/25, Felix Sasaki wrote:
>Hi Christian,
>Lieske, Christian wrote:
>> Hi Felix,
>> So "feature at risk" is everything for which we do not get two implementations?
> Are there other criteria?

I think things are a bit different (unless they have changed recently).
In CR, you have to show that your spec actually got implemented. This
usually means two independent implementations for each feature; it may
also mean two implementations of all required stuff, or so; details
may be negociated with the Director when entering CR.

What happens when you end the CR period, and some things are not implemented?
You can wait (a bit or a lot) longer, or you can go back and change the spec,
and do another last call and CR. Both may not be desirable. Enter
"features at risk": If you defined something as "feature at risk" when
entering CR, and it didn't get implemented sufficiently, you can drop
it from the spec and move on to PR, without going back.

Going back to the current pre-CR period, how do you decide what to make a
"feature at risk"? If you already know you won't get two implementations,
you don't even have to make it a "feature at risk", you can as easily
exclude it. If you see a chance that you won't get two implementations,
then making it a "feature at risk" is a reasonable safety measure.
But even if it's a "feature at risk", the WG should try to work hard
to get the implementations.

Also, for something to become a "feature at risk", it better be a) easy
to remove from the spec (you don't want to get into discussion of what
exactly it means to remove it from the spec if you have to remove it
when going from CR to PR), and b) really something you think that the
world can live without. If it is e.g. something related to universal
access (accessibility, internationalization,...), making such a feature
a "feature at risk" means in effect that you think you are okay even
if your spec does not address accessibility concerns.
Such a thing would be very bad.

Regards,    Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp     
Received on Tuesday, 26 September 2006 06:35:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:04:11 UTC