Re: [Ltru] Re: Great Script Debate "the Next Generation"... (long)

["Doug Ewell" <[e-mail]>]

Mark Davis wrote:

> a) we don't say in the spec that the fields in a record must be 
> considered to be unordered (unless I've missed something).

Well, I can't find it either, in RFC 4646 or Addison's record-jar draft 
or in the Art of Unix Programming.  But I know people have been telling 
me for at least a year that the order of Description fields is 
meaningless, and we can't make it meaningful, because:

a)  record-jar says order is meaningless
b)  RFC 4646 saysorder is meaningless
c)  (a) and (b) above

> b) even if that were the case, we could have
>
>    Script: Hans, Hant

You could certainly do this.  I don't know, however, if trying to order 
the scripts in this way is pertinent to the main goal of improving 
script subtag practice is in line.  If the Registry included either of 
these two Script fields for the Mongolian language:

Script: Mong, Cyrl
Script: Cyrl, Mong

it would have exactly the same meaning that you stated: don't use a 
script that isn't in this list.  Trying to order the entries by usage 
statistics would cause controversy, and would be perceived by some as 
expressing a preference for one script over another, which is not our 
job.

> S:
> Zero means: there isn't any information in the registry about the use 
> of script.

Just like the absence of Suppress-Script.  Fine so far.

> One means: as far as we know, the language tag is only customarily 
> used with this script.

Just like the presence of Suppress-Script.  Fine so far.

> >=2 means: as far as we know, the language tag is customarily used 
> >with all of these scripts, and no others.

This is where it gets better: sort of like an Accept-Script for just 
those two (or whatever).

OK, I'm convinced that this solution might be better than S-S.  The 
question is whether it is "better enough" to justify changing the 
mechanism.

Also, we had better try hard (and fail) to poke holes in this mechanism, 
from all perspectives: ease of understanding, usability by tag producers 
and consumers, ease of administration by ietf-languages.  If there are 
flaws in this mechanism, we'd better find out about them and address 
them before making a change to the system, because we (read: "I") don't 
want to end up scrapping yet another of our own inventions in favor of 
something "better."

> Stability. Our guarantee is that the language tags themselves are 
> stable, not the precise format of the registry. And by stable, that 
> doesn't mean unchanging, either. We can add valid language tags, and 
> we can broaden the semantics of existing language tags.

That kind of instability doesn't bother me half as much as inventing a 
feature one year and getting rid of it the next, or creating "deprecated 
at birth" subtags, or creating mechanisms that we don't really want to 
see used, like extensions.

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://users.adelphia.net/~dewell/
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages


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