<br clear="all">Mark<br>
<br><br><div class="gmail_quote">On Wed, Jul 8, 2009 at 21:04, Doug Ewell <span dir="ltr"><<a href="mailto:doug@ewellic.org">doug@ewellic.org</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;">
<div class="im">Mark Davis ⌛ wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
There are two reasons for having a non-deprecated sh. First, the equivalent hbs is in ISO 639-3, which we are taking as a basis for our expansion in many ways. Having that one macrolanguage be deprecated is just anomalous.<br>
</blockquote>
<br></div>
What's anomalous is for 'sh' to be deprecated in ISO 639-1 but for the equivalent 'hbs' not to be deprecated in 639-3.<br>
<br>
'sh' was given the Deprecated status in the Registry on the basis of its status in 639-1. For us to overturn this decision basically means that we consider 639-3 to be a higher authority than 639-1. I don't see how we justify that.</blockquote>
<div><br>For us to not do it, according to your logic, means that we consider 639-1 to be a higher standard than 639-3. We certainly don't think that; all of the effort we have had over the last few years is *because* we know that 639-3 is far more complete, and well-thought-out, than 639-1 ever was. And we heard quite clearly that the 639-3 committee considered deprecation and decided explicitly against it.<br>
<br>So I have no problem whatsoever in favoring 639-3, since we have to make a choice one way or another.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Second, there is a real use case. According to a good deal of feedback from native speakers in Google, what we call Serbian, Croatian, and Bosnian are really dialects of the one language -- according to the criteria of mutual comprehension. They are really just like the situation with "mo" and "ro".<br>
</blockquote>
<br></div>
They are just like 'mo' and 'ro', with the rather significant exception that ISO 639 hasn't deprecated 'sr' or 'hr' or 'bs'. I'm in full agreement with you on the linguistic issue, but we follow the core standards except where they create an untenable conflict, which this isn't.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Had we had BCP 47 some time ago (and the right country boundaries), they would have been sh-RS (or maybe sh-Cyrl), sh-BA, sh-HR. Having "sh" as a macrolanguage recognizes that situation, and gives us a neutral general code to express the situation.<br>
</blockquote>
<br></div>
We already have 'sh' as a macrolanguage. As you said many times during the course of LTRU development, Deprecated does not mean the subtag can't be used.<br>
<br>
I won't fight too hard against undeprecating 'sh' if others seem to agree with you, but I don't like the potential perception that we're second-guessing ISO 639.<div><div></div><div class="h5"><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>
</div></div></blockquote></div><br>