Subject: Re: [Ltru] extlang & deprecation (was draft updated

From: "Doug Ewell" <[email-masked]>
Date: Tue, 1 Jul 2008 19:31:45 -0600

John Cowan <cowan at ccil dot org> wrote:

>> That's not the definition of Deprecate:
>
> Dictionary definitions of "deprecate" aren't relevant, because it is a 
> term of art among programmers and standardizers.  From Wikipedia:
>
>       In computer software standards and documentation, the term
>       deprecation is applied to software features that are superseded
>       and should be avoided. Although deprecated features remain
>       in the current version, their use may raise warning messages
>       recommending alternate practices, and deprecation may indicate
>       that the feature will be removed in the future. Features are
>       deprecated -- rather than being removed -- in order to provide
>       backward compatibility and give programmers using the feature
>       time to bring their code into compliance with the new standard.
>               http://en.wikipedia.org/wiki/Deprecation

Actually, while this disagreement over the use of the word "deprecated" 
may seem academic, I think it cuts to the very heart of the X-Y versus Y 
controversy.  People on this list -- even the same person at different 
times; I'll dig up quotes if asked -- have said that (1) deprecated 
subtags are perfectly fine to use, because they'll just get normalized 
away, AND that (2) deprecated subtags are something to be avoided at all 
costs.

We can't have it both ways, and expect those on the opposite side of 
this battle to accept their preferred forms being "deprecated" on the 
basis of argument 1 ("it's still OK to use them") when we still have 
draft text, and arguments on the list, that their use will be considered 
non-conformant.

As I've said before, we can get so caught up in our own terminology that 
we forget that the general tagging populace may not understand these 
terms the way we understand them -- and without a glossary, we can't 
fault them for devising their own definitions.  I agree with John that 
the use of "deprecated" in the programming world is different from the 
mainstream dictionary definition, which evokes visions of burning at the 
stake, but we don't even agree among ourselves exactly what it does 
mean.

Until we do that, and unless we decide formally that "deprecated" has 
the gentler meaning of "OK to use, but will be normalized away," the 
battle lines between the "zh-cmn" crowd and the "cmn" crows will 
continue to be drawn.

--
Doug Ewell  *  Arvada, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: Shawn Steele <[email-masked]>
Date: Tue, 1 Jul 2008 21:49:46 -0700

> mainstream dictionary definition

My interpretation of deprecated in computing is "this is obsolete and replaced by something newer".  Presumably it still works, but I think in a code review you'd typically get dinged for using deprecated APIs when newer behavior was available.  Not quite a burning at the stake, but still not good to use.

Given the negative press that sometimes occurs in some reason for no particular reason, it seems that using deprecated stuff in computing could even open some of us up to nasty remarks whether or not the reasoning was sound.

- Shawn

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 1 Jul 2008 22:34:42 -0700

>
> My interpretation of deprecated in computing is "this is obsolete
> and replaced by something newer".  Presumably it still works, but I
> think in a code review you'd typically get dinged for using
> deprecated APIs when newer behavior was available.  Not quite a
> burning at the stake, but still not good to use.
>

Yes, but we are not talking about code here. We're talking about value. Deprecated values are still legal values, part of the domain of values one's code MUST deal with to be a conforming implementation. "art-lojban" and "i-hak" are also deprecated, but code must still deal with those values. So too one must deal with the deprecation of either "X-Y" forms or "Y" forms. The deprecation of one in favor of the other suggests that an implementation should replace one with the other (when not otherwise obligated). In fact, my argument in favor of a particular form of deprecation partially rests on the observation that some mappings are easier to work with than others.

Addison