<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
<BR>Hi!<BR>A generic prefix field is very broad indeed and cannot be narrowed later!<BR>But I am not particularly tied to one or the other solution as far as generic and specific prefixes go;<BR>
however, there is no way I would consider registering all possible specific prefixes at once for [alalc97]--just those requested. <BR>Also, I am sort of in favor of deprecating [heploc] for the logic of things<BR>(though it seems a shame to register a subtag and then deprecate it; it's not a good precedent to set normally I don't think)!<BR>
<BR>Phillips, Addison addison at amazon.com <BR>Wed Nov 18 16:48:40 CET 2009 <BR>>> > For my needs, this approach would be sufficient. Indeed, would it<BR>>> > be a<BR>>> > workable short-term solution to change my variant subtag request<BR>>> > to<BR>>> > the subtag "alalc97", which could be processed on its own merits<BR>>> > in<BR>>> > the short term (with only the prefix ru-Latn), then modified to<BR>>> > include other possible prefixes (cs-Latn, tt-Latn, etc.) if the<BR>>> > community so decides?<BR>That is a possibility--as prefixes can always be added. <BR>
And it perhaps solves the problem of deprecation in a case where the romanization scheme is modified before a particular prefix is requested.<BR>>> <BR>>> It would be easy enough to specify the range of use for alalc97 now.<BR>
> I'm not so sure.<BR>
> If a subtag has Prefix fields, then it should try to list the full range of appropriate prefixes. <BR>
> This may be a quite lengthy list and difficult to maintain. If it has *no* prefix, then it is what we are calling a <BR>
> "generic variant". Lack of a prefix should not imply that a subtag is useful with every possible language tag. It <BR>
> merely means that the registry does not specifically recommend a fixed set of language tags for use.<BR>
>> <BR>>> > I also have a slight concern that a broadly defined "alalc97"<BR>>> subtag<BR>>> > would be overlap with existing romanization variants; to draw<BR>>> from the<BR>>> > most recent romanization discussion, text in the LOC Hepburn<BR>>> > romanization of Japanese could be marked as either<BR>>> > jp-Latn-hepburn-heploc or jp-Latn-alalc97.<BR>>> <BR>>> Then we specify the range of use for alalc97 now, and explicitly<BR>>> omit Japanese since it is already covered.<BR>
> I would prefer, as noted, to deprecate the existing subtag 'heploc' instead. Deprecation does not make the subtag illegal. It provides a mapping to a Preferred-Value.<BR>Somewhat agreed here though it's only been seven weeks. But it would make sense to register alalc97 for both Russian and Japanese I guess--that would insert some logic and consistency and unity in the variant subtag list.<BR>> <BR>>> > Similarly, if a new set of ALA-LC romanization tables is released,<BR>>> but it differs only in its<BR>>> > treatment of a few languages, would we then have identical text<BR>>> that can be marked equally well as ru-Latn-alalc97 or ru-Latn-<BR>>> ala09 ?<BR>>> <BR>>> Then alalc09 is only registered for use with the changed (or new)<BR>>> languages.<BR>
> Note that, assuming 'alalc97' is not a generic variant and has Prefix fields in its record, wholesale removal of Prefixes is not permitted (RFC 5646, Section 3.1.8), nor is there a mechanism for deprecating only certain uses of a subtag. However, a comment field could be inserted guiding users towards 'alalcXX'. If 'alalc97' is generic, then a new subtag could have prefixes or could also be generic with a note to provide guidance on usage.<BR>This is a problem. I still like the idea of registering this subtag with the list of possible prefixes (two at this moment; Russian and Japanese); at least more prefixes can be added later; if we make this a generic prefix, it gives everyone the use of this subtag without further ado of course--if that is needed. <BR>But this is a much more specific case than fonipa and fonupa and it seems strange having both generic.<BR>
> The registry does not exist to completely remove all possible choice (and thus all possible error) in language <BR>
> tagging, so I tend to favor rather less documentation in the registry.<BR>
<BR>Hmm. Of course, it would be nice to remove the possibilities for error as much as a list of subtags can.<BR>
Best,<BR>
--C. E. Whitehead<BR><A href="mailto:cewcathar@hotmail.com">cewcathar@hotmail.com</A><BR>> Addison<BR>
> Addison Phillips<BR>> Globalization Architect -- Lab126<BR>
<BR> <BR> </body>
</html>