Re: AW: Features at risk

Hello Martin,

Many thanks for your detailed explanation. I should have provided that in
the first place.

I think there is one area where an implementation might create issues
which we don't want: the "pointer" attributes for ruby. I also think that
we could get rid of them easily (re your proposal a) below) and I think
they are not related to universal access (re your prosoal b) below) ).

The other data categories should go through CR without problems, see
http://lists.w3.org/Archives/Public/public-i18n-its/2006JulSep/0405.html .

Felix


>
> 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?
>>
>>Yes.
>>
>> Are there other criteria?
>>
>>No.
>
> 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 10:37:53 UTC