Timetable for action: May 31 is suggested

[Michael Everson]

At 06:49 +0000 2003-05-27, John Clews wrote:

>  > >It's a request for action - not rhetoric.
>>
>>  The *action* we are undertaking is discussion.
>
>But your job as Language Tag Reviewer is to decide whether to add
>specific tags.

Well gosh, John, I can't decide about these because there aren't 
clear guidelines about them or the implications of them. Do I have to 
add yi-Hebr now? Somebody says yes. Do people want to parse the tags? 
They do. Can country elements interact with the script tags? 
Evidently. What format should the parsing have? I don't know, and it 
is NOT my job to decide arbitrarily. Or is it?

>If the actions of the Language Tag Reviewer are seen as unsuitable,
>a process exists to appeal. The use of that is now looking 
>increasingly likely.

I *am* doing my job, as I understand it, John.

>If it's such a new thing, why have you yourself spent many man-months
>in developing ISO 15924: Codes for representation of names of
>scripts, and trying to persuade ISO/TC37/SC2, and then persuading
>ISO/TC46/SC2 to take it on as a new Work Item for an ISO standard?

You're being silly. Those would work perfectly in a script= tag, in 
library database fields, and so on.

>Your more recet rejection of the combination of script codes with
>language codes seems not only to call into question your role as
>Language Tag Reviewer,

I take umbrage at this.

>having already registered one of this sort (yi-Latn), but rejecting 
>others on principle, but it also calls into question the value of 
>ISO 15924.

No it doesn't. The yi-Latn "precdent" seems to have raised all sorts 
of new questions. Is there a default script for languages? Will 
yi-Hebr have to be added now, as one person suggested? What about 
yi-US-Latn vs yi-Latn-US -- which should it be? -- isn't one 
structure implied by de-DE-1909? Is that the structure we want for 
zh-Hant and zh-Hans?

>2. Alternative approach
>
>The only arguable possibility - which somebody mentioned earlier, was
>instead of having a structure like
>
>         lang=lan-Scrip
>
>where lan represents language code; Scrip represents script code,
>
>would be to have something else like two separate entities, each
>specified in a separate RFC, one of which is RFC 3066.
>
>         lang=lan
>         script=Scrip

Yes, I had suggested that a long time ago. Apparently this will fail 
because current implementations want to conflate script within 
language tags.

>If a separate RFC were developed for the last of these, in addition,
>it would have to be accepted that for historical reasons there were
>one or two tags which had been allocated before, such as
>
>         lang=yi-Latn
>
>and - if you register what has been requested this week, again
>it would have to be accepted that for historical reasons there were
>one or two tags which had been allocated before, such as
>
>         lang=az-Cyrl
>         lang=az-Latn
>         etc.
>
>Suitable deprecation notices about lang=az-Cyrl and lang=az-Latn
>might be added to any revised/superseding RFC(s) in the future, if
>any problem did arise.

The interaction with country codes has not been addressed, has it? 
EVEN IF THESE PARTICULAR PROPOSALS DON'T HAVE COUNTRY CODES IN THEM 
THE PROBLEM STILL EXISTS. As tag reviewer, I think it best that we 
decide what we want to do *before* certain tags are added.

What do we do with Chinese? We have tags for a number of Chinese 
languages. None of these have script tags attached. What shall we do 
with the syntax of these regarding script tags?

>For the good of my health, would you - or he - recirculate a copy of 
>this as an email, or point to a URL, which would see if this adds 
>aything to the debate or not? I don't recall it, and the continued 
>allusion to it as "Peter Edberg's discussion paper" or similar, 
>without any detail of what was in it just doesn't help people decide 
>whether this is a useful thing to look at, or what some might see as 
>just a delaying tactic.

Peter has said he will forward it. Peter, please do this right away.

>  > For the record, I agree pretty much with Ken. This stuff is a cheap
>  > hack, and it's idiotic that we have to add stuff like this into
>>  <lang=> tags when it really ought to be in <script=> tags.
>
>Well, I'm glad you've decided not to go in for rhetoric :-)

Well I feel rather put-upon and frustrated myself.

>In passing, I saw many other parts of Ken's text which to me implied
>that you should just get on and register the language tags.

I would rather have the issues regarding interaction between 
language, script, and country codes in these language tags be SETTLED 
before I do that.

James Seng: What is best? zh-Hans-SG? zh-SG-Hans? zh-guoyu-Hant-SG? 
Etc. etc. etc. I want this question answered before I approve the 
kinds of tags proposed. I think I am RIGHT to insist on this.

>  > We are doing more than just deciding whether to satisfy Mark's
>>  immediate requirements. We are making decisions which can help Yours
>>  Truly actually do this stuff more gracefully in future.
>
>Well, wouldn't a revision of RFC 3066 which included the possibility
>of combining language tags and script tags, allow everybody to do
>this stuff more gracefully in future?

I myself don't see a need to wait for a complete revision, which will 
take a long time. We could set policy on the PROBLEM raised without 
waiting for a formal revision. But *I* don't want to set such a 
policy by fiat. Hence my insistance on "delay".

>It seems to me that there is a confusion between
>(a) dealing with processig requested tags now, and
>(b) revision of RFC 3066,
>and that (b) is just being used as a delaying tactic against (a).

I think it is offensive to suggest that I am delaying for the sake of delay.

>  > We *DO* need to have a policy on these matters. We *DO* need to have
>>  a consensus decision on syntax. Is it to be zh-Hans-SG or zh-SG-Hans?
>>  Do you know? Do you care? Does it matter?
>
>Those weren't requested. This merely appears to be another delaying tactic.

Mark's proposals have implications regarding other tag structures, 
and that is why I am not accepting them at present. Is this in any 
way unclear?

>  > And to Addison: the palpable thing you're looking for is that these
>>  proposals are crap, they are hacks for a specific locale tagging
>>  system which itself ought to have been rethought and rewritten, and
>>  now it's dumped on this poor RFC.
>
>Again, I'm glad you've decided not to go in for rhetoric :-)

In a perfect world, script tags and language tags would not be 
conflated in language tags, in my view. We may do so -- after we have 
dealt with the syntax issues.

>  > And to John Clews: Your Reviewer has about a week in Dublin before he
>>  has to got to Baltimore for the greater glory of encoding Cuneiform,
>>  and then when he gets back he goes to Oxford for the greater glory of
>>  encoding medieval weirdo Latin letters,
>
>We're not concerned with what the rest of us do: just with what you
>do or don't do - it's you that has taken on the task of
>Language Tag Reviewer.

I am not a rubber-stamper. I am not a number. I am a free man! :-)

>Well, you have a week before you go to Baltimore: good, that gives
>you time to do some action - which you have delayed doing before.
>
>It seems to me that you are required by the RFC and your role as
>Language Tag Reviewer, to either allocate tags, or give a
>justification as to why not.

I think I have done so here at least.

>Getting whatever actions done now would be far better, than
>waiting for further delays cuased by travel to Baltimore and then
>Oxford, and then people start to go on summer holidays, and so on:
>the possibilities for delay are endless.

If you posit that I am enjoying this process and have some interest 
in dragging this argument out for its own sake you are definitely 
mistaken.

>  > and he is sure that nothing
>>  is going to happen between now and the middle of June,
>
>so why is the middle of June any better than now for this?

Because the structural questions have not been dealt with and resolved.

>  > which gives
>>  Mark and the rest of you PLENTY of time to talk to Peter Edberg and
>>  Ken and Harald and come up with a MATURE position and policy
>>  document, so that Your Reviewer doesn't have to be BLAMED when he
>  > balks at encoding things that he thinks are dodgy.
>
>Nobody is going to blame you for allocating these codes.
>Several people will blame you for not allocating these codes.

I've a thick skin. I think I am doing my job.

>It strikes me that the only alternative - and Michael may be right
>when he talks about a task for "the rest of you" - would be to
>determine whether a separate mechanism, such as
>
>(a)     lang=lan
>(b)     script=Scrip
>
>(where lan represents language code; Scrip represents script code)
>might be possible, with the first already defined in RFC 3066, and
>the second to be defined in a completely separate RFC, might be a
>better solution anyway.

But this will not work with, apparently, the software that Mark is 
using now; he needs to use language tags only to do what he needs to 
do.
-- 
Michael Everson * * Everson Typography *  * http://www.evertype.com