Subject: RE: [Ltru] Re: Proposed Text for Moving Forward

From: "McDonald, Ira" <[email-masked]>
Date: Sun, 17 Apr 2005 12:11:45 -0700

-1

Sigh...until this message we had an emerging concensus.

Non-specific "use tags wisely" is much WORSE than no
statement at all.

Addison has proposed a low-cost unambiguous solution to
a real-world problem.

Tag matching may go into some other spec (lousy idea
IMHO, because the registry format has to be intimately
coupled to standard matching algorithms).  But actually 
generating tags in client applications needs to have 
normative guidance in RFC3066bis itself or we're all 
wasting our time.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On
> Behalf Of Doug Ewell
> Sent: Sunday, April 17, 2005 4:05 AM
> To: LTRU Working Group
> Subject: [Ltru] Re: Proposed Text for Moving Forward
> 
> 
> Addison Phillips <addison dot phillips at quest dot com> wrote:
> 
> > I agree, Mark, that the full effect can be achieved with only one
> > field and that your proposal is superior in a number of 
> regards (fewer
> > moving parts, ease of maintenance, ease of application).
> >
> > I proposed two, though, for a reason. One of the objections was that
> > we didn't document when a particular script really ought to be used
> > (i.e. that you really should start to use zh-HanX-XX in 
> preference to
> > zh-XX).
> 
> I know I said I would back off and not get involved in the
> default-script issue.  OK, so I lied.  Sorry about that.
> 
> AFAICT, this whole issue started with the concern that people 
> would use
> a script subtag in cases where it was generally thought to be (a)
> unnecessary, because the intended script would be obvious, and (b)
> undesirable, because it would interfere with left-prefix 
> (RFR) matching.
> 
> The standard example was "en-Latn-US."  The case was made that the
> overwhelming majority of written U.S. English text is written in the
> Latin script, so the added flexibility of being able to specify the
> script would be largely unnecessary, and in particular it would be
> overshadowed by the inability of existing left-prefix matching
> algorithms to match "en-Latn-US" with "en-US" (sometimes 
> generalized to
> "broken backward compatibility").
> 
> This was the foundation of "default script": certain languages like
> English could be listed as having a default script of Latin, 
> so that tag
> generators could avoid creating tags like "en-Latn" or "en-Latn-US"
> whose disadvantages would outweigh their advantages.
> 
> Of course, in certain circumstances you might have English written in
> Braille, or even in Cyrillic, and most if not all seemed to agree that
> in these rare circumstances it would be acceptable to generate
> "en-Brai-whatever" or "en-Cyrl-whatever."
> 
> The standard counterexamples were "zh-Hans" and "zh-Hant."  
> The case was
> made that Chinese is commonly written in both of these script 
> variants,
> and it would often be beneficial to include script information, to the
> point of perhaps being more important than strict compatibility with
> left-prefix matching algorithms.  Languages like Chinese and 
> Azerbaijani
> and Serbian, after all, were the major use cases for the 
> introduction of
> script subtags in the first place.
> 
> So unlike "en-Latn", it would not be discouraged to write "zh-Hans" or
> "zh-Hant", or either of these followed by a region subtag.  Of course,
> just like English, Chinese could also be written in a less obvious
> script like Braille or Cyrillic, and so "zh-Brai" and 
> "zh-Cyrl" ought to
> be allowed as well.
> 
> I concede that because of the stated predominance of 
> processes that use
> left-prefix matching, it might be beneficial to define a 
> default script
> for common languages that are written in a single script 99.9% of the
> time.  I still don't know where the authority comes from to 
> decide which
> languages and which scripts get marked in this way -- definitely not
> from ISO or documented registrations or deterministic rules, like
> everything else in the registry -- but I assume that would be 
> worked out
> in due course.
> 
> What I do NOT understand is how this has expanded to telling 
> people when
> they SHOULD use script subtags, and how the set of allowable subtags
> should be limited in some way.
> 
> There may well be cases where "zh" or "zh-CN' or "zh-TW" is 
> all that is
> needed, and there is certainly existing data that uses such tags.  I
> don't see any justification for discouraging such usage, even 
> if we have
> defined a way to tag Chinese data more precisely.  Likewise, 
> if there is
> no prohibition against writing "en-Brai" or "en-Cyrl", then I see no
> reason to prohibit or discourage "zh-Brai" or "zh-Cyrl" either.  A
> "required-script" field would do exactly this, by listing 'Hans' and
> 'Hant' but not others.
> 
> This is too prescriptive.  It tells people how they SHOULD 
> tag data, not
> just in terms of "tag content wisely" or "don't be 
> excessively precise,"
> but on a specific language-by-language basis.  It assumes, implicitly,
> that this group or ietf-languages has the expertise and authority to
> make this judgment.  Unlike default-script, required-script 
> does nothing
> to solve the left-prefix matching problem, and as such, I don't think
> it's within the scope of the charter.
> 
> I propose the following:
> 
> 1.  An optional, informative default-script field that would 
> suggest to
> tag generators that they not use that particular script 
> subtag together
> with that particular language subtag.  This field could be added,
> changed, or removed at any time.  (It doesn't matter much 
> what the field
> is called, and I renew my suggestion that we not try to 
> inject too much
> deep meaning into the names of fields, or assume that users 
> will derive
> deep meaning from them.)
> 
> 2.  NO requirement within the draft that tag generators "must not" use
> script subtags in any given scenario.  The text in draft-01 that
> discourages the use of a script subtag "unless it conveys additional
> information" should be adequate.
> 
> 3.  NO mechanism to tell tag generators that they "should" 
> use a script
> subtag together with any particular language subtag, and *especially*
> not one that lists the "expected" script subtags while 
> excluding others.
> If tag generators opt to create a tag such as "zh-TW" that "may be
> ambiguous without script information," that should be up to them.
> 
> -Doug Ewell
>  Fullerton, California
>  http://users.adelphia.net/~dewell/
> 
> 
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru
> 

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

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 17 Apr 2005 16:35:16 -0700

> Sigh...until this message we had an emerging concensus.

I thought you were one of the primary objectors to excessive use of
script subtags.  Now you're supporting an invention that tells tag
generators when they MUST insert a script subtag?

-Doug Ewell
 Fullerton, California