Subject: Re: [Ltru] Consensus call: extlang

From: "Doug Ewell" <[email-masked]>
Date: Mon, 26 May 2008 00:56:08 -0600

Mark Davis <mark dot davis at icu dash project dot org> wrote:

> This is crazy; we do not have consensus to introduce a major 
> architectural change from RFC4646.

Again without stating a personal preference for or against extlangs --  
remember I voted B-B --  I'd be interested to know exactly how 
reinstating them would constitute a "major architectural change from 
RFC4646."  RFC 4646 was built from stem to stern with the underlying 
assumption that the next revision would bring extlangs.  They are 
defined in Section 2.2.2 of RFC 4646 and referenced throughout the 
document.  Indeed, we had to change our ABNF just to get rid of them.

--
Doug Ewell  *  Arvada, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

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

---

From: Peter Constable <[email-masked]>
Date: Mon, 26 May 2008 00:41:56 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Doug Ewell

> ... I'd be interested to know exactly how
> assumption that the next revision would bring extlangs.

Well, it is and it isn't: we allowed for them in the syntax of 4646, but we didn't implement them. It's the actual implementation that would represent a significant departure. But I would agree that Mark's objection is a bit overstated.

At the same time, I understand the frustration (though, of course, many here are frustrated.) I do think there have been some advances of late, although it's not exactly obviously that consensus is quickly approaching. A straight up/down kind of vote was asked for, yet it seems to me that several people had qualified views. I would have been happier if people were asked to respond succinctly "I like/object to extlang/no-extlang because... " -- i.e. to get to what people see as the core concerns. For instance, I got a clearer sense of what Karen's core concerns were as a result of this vote. I would have liked a little more chance to see if her concerns could be addressed without the significant change entailed in re-inserting extlang into the draft. At this point, though, it's seems like that chance may be gone.

It doesn't help to hear exactly the same points back and forth repeated over and over; that just adds to frustration and a sense that we are spinning wheels. It also doesn't help to have people arguing from a one-track point of view that treats one pet concern as though it were representative of all relevant scenarios -- no one concern or scenario is so broadly representative. Some not-super-realistic (IMO) scenarios have been put forth to make a point one way or another, and it does help to see what happens at the edges, but it's not helpful if we forget how (un)realistic particular scenarios are.

Macrolanguages are a mixed bag -- they're not all the same. Chinese is only one case; Norwegian is only one case; Arabic is only one case. Macrolanguages are also a limited set in the big scheme of things; and only a small portion involve significant existing usage (notice that we keep coming back to a small set of examples), but I think it's the widespread existing usage of some macrolanguage IDs that creates the concerns people have -- for those cases only. For example, consider Cree: if we were to say, "Content SHOULD be tagged using the language subtag for the specific, encompassed language, though the language subtag for the macrolanguage MAY be used in a given application context if there are particular reasons," I doubt there'd be much confusion over what guidance was being given on how to tag, and I doubt there would be much concern over whether filtering/lookup/fallback could work in a reasonably acceptable way -- not perfect by any means, but workable. Of course, I understand concerns over arbitrariness in trying to partition macrolanguage cases into the widespread/not widespread use.

I better stop here... I fear I'm starting to ramble.

Peter

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 26 May 2008 10:31:48 -0600

Peter Constable <petercon at microsoft dot com> wrote:

>> ... I'd be interested to know exactly how reinstating them would 
>> constitute a "major architectural change from RFC4646."  RFC 4646 was 
>> built from stem to stern with the underlying assumption that the next 
>> revision would bring extlangs.
>
> Well, it is and it isn't: we allowed for them in the syntax of 4646, 
> but we didn't implement them. It's the actual implementation that 
> would represent a significant departure.

We designed the extension mechanism in RFC 4646, but haven't implemented 
that either.  If someone wrote an extension RFC for singleton 'a' and we 
started having tags of the form "en-a-whatever", would that constitute a 
major architectural change from RFC 4646?

---

From: Peter Constable <[email-masked]>
Date: Mon, 26 May 2008 10:09:09 -0700

> From: Doug Ewell [mailto:[email-masked]]
> Sent: Monday, May 26, 2008 9:32 AM

> major architectural change from RFC 4646?

No, though extensions would probably be used for tagging entirely new kinds of information. Using aa(a)-bbb(-ccc) for exactly the same category of information (language in the strict sense) when only aa(a) has been used before (except for a set of registered tags for Chineses) would be a significant change, I think.

But I did agree we you at least to the extent that the objection was overstated.

Peter