Subject: [Ltru] Possibly a way forward? (was extlang & deprecation (was draft updated...))

From: "Mark Davis" <[email-masked]>
Date: Mon, 7 Jul 2008 21:23:48 -0700

I ran the following by a few people, and it may offer a way out of our
current situation,  by taking the following steps.

   1. Tie "Preferred Value" more closely to canonicalization.
   2. Decouple "Preferred Value" and "Deprecated"; a subtag can have
   a Preferred Value without being Deprecated.
   3. Make it very clear that when there is a Preferred Value or when there
   is Deprecated, the tag or subtag is still valid, and perfectly acceptable.
   4. In particular, make it clear that the X-Y values are perfectly
   acceptable, and as valid as the Y forms.
   5. Add that some implementations will find it more convenient to have
   their own canonical form. Give examples of "iw" for Java, and of X-Y forms.

Can anyone not live with the current draft plus these changes?

Mark

On Tue, Jul 1, 2008 at 6:31 PM, Doug Ewell <[email-masked]> wrote:

> 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
>
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Phillips, Addison" <[email-masked]>
Date: Mon, 7 Jul 2008 22:33:13 -0700

I think this is misguided. The problem here that we seem to be struggling with is that we don’t wish to insinuate that one form or the other is “better” because we cannot agree amongst ourselves which form is better… or we fear that some nameless parties will object later (why they don’t object now I don’t understand---it’s a kind of DoS attack on the WG not to say what one prefers now).

I cannot understand how a subtag can have a “preferred value” (implying that it is at least “not preferred”) and not say that it is deprecated. Deprecation is not the end of the world for a subtag. If what we’re saying is that deprecation of (either) one of the forms is a non-starter, then let’s go with:

1.       There are two forms Y and X-Y.

2.       Neither form is preferred and neither form is deprecated. Either MAY be used to form the language tag.

3.       Choosing one form or the other has implications, especially for naïve matching algorithms (list these implications where known)

That strikes me as a workable compromise if we cannot agree to deprecate one form or the other. Implementations are still free to choose one form over the other and still free to “normalize” tags to that form for processing.

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Davis
Sent: Monday, July 07, 2008 9:24 PM
To: Doug Ewell
Cc: LTRU Working Group
Subject: [Ltru] Possibly a way forward? (was extlang & deprecation (was draft updated...))

I ran the following by a few people, and it may offer a way out of our current situation,  by taking the following steps.

 1.  Tie "Preferred Value" more closely to canonicalization.
 2.  Decouple "Preferred Value" and "Deprecated"; a subtag can have a Preferred Value without being Deprecated.
 3.  Make it very clear that when there is a Preferred Value or when there is Deprecated, the tag or subtag is still valid, and perfectly acceptable.
 4.  In particular, make it clear that the X-Y values are perfectly acceptable, and as valid as the Y forms.
 5.  Add that some implementations will find it more convenient to have their own canonical form. Give examples of "iw" for Java, and of X-Y forms.
Can anyone not live with the current draft plus these changes?

Mark
On Tue, Jul 1, 2008 at 6:31 PM, Doug Ewell <[email-masked]<mailto:[email-masked]>> wrote:
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:

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.

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

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 7 Jul 2008 23:46:00 -0600

For the record, either the X-Y or Y form is acceptable to me.  I'm not 
planning any late surprises.

I would like to see X-Y be allowed *somehow*, even if it is deprecated 
so strongly that I have to register with the police AND all the 
neighborhood kids will make fun of me if I use it.  But even if the WG 
decides it must be only Y (which I don't think will happen), I will go 
along with it.

The worst thing of all is to continue this delay indefinitely so that 
these 7,200 additional languages cannot be part of an IETF language tag 
at all.  Talk about a denial of service.

----- Original Message ----- 
From: Phillips, Addison
To: Mark Davis ; Doug Ewell
Cc: LTRU Working Group
Sent: Monday, July 7, 2008 23:33
Subject: RE: [Ltru] Possibly a way forward? (was extlang & deprecation 
(wasdraft updated...))

I think this is misguided. The problem here that we seem to be 
struggling with is that we don’t wish to insinuate that one form or the 
other is “better” because we cannot agree amongst ourselves which form 
is better… or we fear that some nameless parties will object later (why 
they don’t object now I don’t understand---it’s a kind of DoS attack on 
the WG not to say what one prefers now).

I cannot understand how a subtag can have a “preferred value” (implying 
that it is at least “not preferred”) and not say that it is deprecated. 
Deprecation is not the end of the world for a subtag. If what we’re 
saying is that deprecation of (either) one of the forms is a 
non-starter, then let’s go with:

1.       There are two forms Y and X-Y.
2.       Neither form is preferred and neither form is deprecated. 
Either MAY be used to form the language tag.
3.       Choosing one form or the other has implications, especially for 
naïve matching algorithms (list these implications where known)

That strikes me as a workable compromise if we cannot agree to deprecate 
one form or the other. Implementations are still free to choose one form 
over the other and still free to “normalize” tags to that form for 
processing.

Addison

Addison Phillips