Ah, I am now finally understanding what you are concerned about. The main problem is that the Preferred value really should be a set, in the case of regions. Then we would have<br><br>Before:<br>YU -> CS<br><br>After<br>
YU -> {RS ME}<br>CS -> {RS ME}<br><br>and the connection is maintained. But we -- unfortunately -- don't have that ability, and I'm not suggesting addition at this late date (although perhaps for a future version - in CLDR we maintain that information because it is important for implemenations)!<br>
<br>So removing CS breaks the equivalence class relation between YU and CS.<br><br>I'm starting to change my mind about the wisdom of removing the Preferred value. After all the purpose is for canonicalization, and xx-YU and xx-CS should have the same canonical form. We lose that if we drop the value.<br>
<br clear="all">Mark<br>
<br><br><div class="gmail_quote">On Fri, Feb 27, 2009 at 12:55, Tex Texin <span dir="ltr"><<a href="mailto:textexin@xencraft.com">textexin@xencraft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
1) I used YU/CS as a shorthand for identifying a subtag that could be either.<br>
2) I understand the inaccuracy between YU and CS. That was not offered as the reason for the change however, at least in the mails I saw. Perhaps it was an implicit motive.<br>
<br>
3) I understand that there isn't a requirement to change tags. I'll make the case another way-<br>
At some point in time a user attempts to find documents tagged for Yugoslavia.<br>
The search engine, using the then current registry data noting the preferred value relationship, matches either YU and CS.<br>
<br>
Another user searches for documents for Serbia.<br>
The search engine, using the then current registry data noting the preferred value relationship, matches either YU and CS.<br>
<br>
The results are in some sense accurate and complete given the history of the subtag.<br>
<br>
After the change in the preferred value relationship, the search engine does not search for both, since the registry does not indicate a relationship. Only one or the other subtag is used for each query. However, the query results are now incomplete since documents for YU may have been tagged with the one-time preferred tag of CS.<br>
<br>
4) Comments are a good thing for recording rationale and tangential history. However, implementers are not going to go thru and read the comments on any or all tags in order to make a correct implementation. They are going to implement based on the schema and operate with the data values.<br>
<br>
5) I think the registry should stay as it is with respect to YU and CS.<br>
As CS is now being used, deprecated or not, I don't see a compelling motivation to change the value back to YU. Doing so would just compound the confusion over the two subtags.<br>
<br>
6) I don't expect users to be walking the registry in any event but to use a software package that recommends the optimal value. If that software executes a few extra machine cycles to get to CS, so be it. (And that is only if the results aren't put into a precompiled form.)<br>
<br>
7) I would not argue that preferred value relationships should never change. But the motivation to make a change should be compelling enough to outweigh the impact of making ambiguous the existing tagged data.<br>
<br>
8) Separate topic- The number of countries in the world seems to grow. This suggests to me that regions being subdivided is not going to be a rare event. Perhaps there should be a mechanism to indicate subtags that have later been split, so instead of one preferred value, there is a way to indicate that a tag has been deprecated in favor of two or more possible values.<br>
<font color="#888888"><br>
tex<br>
</font><div class="Ih2E3d"><br>
<br>
-----Original Message-----<br>
From: <a href="mailto:ietf-languages-bounces@alvestrand.no">ietf-languages-bounces@alvestrand.no</a> [mailto:<a href="mailto:ietf-languages-bounces@alvestrand.no">ietf-languages-bounces@alvestrand.no</a>] On Behalf Of Doug Ewell<br>
Sent: Friday, February 27, 2009 5:21 AM<br>
To: <a href="mailto:ietf-languages@iana.org">ietf-languages@iana.org</a><br>
Subject: Re: Proposal to remove Preferred-Value field for region YU in LTRU<br>
<br>
</div><div><div></div><div class="Wj3C7c">Tex Texin <textexin at xencraft dot com> wrote:<br>
<br>
> Historically, it was a concern that codes might change.<br>
> If I use the registry to choose the preferred value for a region, and<br>
> that preferred value can change, then isn't it tantamount to the code<br>
> changing?<br>
<br>
This would have been a good question for the LTRU group back when the<br>
decision was made to allow Preferred-Value to change. I'm guessing this<br>
was about a year ago, but I would have to look it up.<br>
<br>
> If I had data that would be represented by YU/CS and after the<br>
> preferred value is removed it should instead be YU, that seems like a<br>
> problem.<br>
<br>
I guess I'm not sure what you mean by "YU/CS" in this context. A<br>
language tag contains at most one region subtag, of course.<br>
<br>
> Especially since the relationship between CS and YU becomes lost.<br>
<br>
Speaking to this particular case and not to the general principle of<br>
allowing P-V to change...<br>
<br>
It has been argued frequently on LTRU that the relationship between CS<br>
and YU is not what it appears, because the country identified as YU<br>
changed its nature dramatically between 1991 and 2003, in a way that was<br>
pertinent to language identification, by shrinking from the original<br>
"Yugoslavia" to just Serbia and Montenegro. This viewpoint holds that<br>
data tagged as "something-YU" is already ambiguous as to "which YU" is<br>
intended. This is really just a special case of the problem that<br>
country codes as language modifiers are less than perfectly precise.<br>
<br>
> Also, it may not be clear which CS records should be restored to YU.<br>
<br>
There is never any presumption that someone will go through and retag<br>
data. Section 3.1 says, "In particular, the 'Preferred-Value' field<br>
does not imply retagging content that uses the affected subtag." To me<br>
this implies that a change or deletion of P-V doesn't imply retagging<br>
either.<br>
<br>
> I don't see that the fact that the target preferred value of YU is<br>
> also deprecated is a good reason to break the relationship at this<br>
> point. We still end up with deprecated codes with no preferred value<br>
> to go to, so why introduce an unnecessary change?<br>
<br>
So that users will not have to follow a chain of arbitrary length to<br>
determine the best subtag -- or in this case, to reach a dead end.<br>
<br>
--<br>
Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14<br>
<a href="http://www.ewellic.org" target="_blank">http://www.ewellic.org</a><br>
<a href="http://www1.ietf.org/html.charters/ltru-charter.html" target="_blank">http://www1.ietf.org/html.charters/ltru-charter.html</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/ietf-languages" target="_blank">http://www.alvestrand.no/mailman/listinfo/ietf-languages</a> ˆ<br>
<br>
_______________________________________________<br>
Ietf-languages mailing list<br>
<a href="mailto:Ietf-languages@alvestrand.no">Ietf-languages@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/ietf-languages" target="_blank">http://www.alvestrand.no/mailman/listinfo/ietf-languages</a><br>
<br>
_______________________________________________<br>
Ietf-languages mailing list<br>
<a href="mailto:Ietf-languages@alvestrand.no">Ietf-languages@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/ietf-languages" target="_blank">http://www.alvestrand.no/mailman/listinfo/ietf-languages</a><br>
</div></div></blockquote></div><br>