Subject: [Ltru] prefixes for date variants (was Re: Generic variants and Armenian dialects)

From: "Peter Constable" <[email-masked]>
Date: Mon, 4 Sep 2006 08:21:07 -0700

(moving to LTRU)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Constable
Sent: Monday, September 04, 2006 7:11 AM
To: [email-masked]
Subject: RE: Generic variants and Armenian dialects

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

> > The only bit of your message that worries me is the discussion of
> > "en-1901"...

> Perhaps LTRU
> should consider defining a distinction between this type of "date"
> variant, which could in theory apply to more than one language (even
> though the reforms themselves would be different), and the "usual" type
> such as Resianic or Boontling or Scouse or Eastern [Armenian], which in
> theory could not ("Eastern Quinqui" would not have the same relative
> meaning as "Eastern Armenian," except geographically).

The portion you quoted doesn't appear to prevent us from specifying multiple prefixes for a date variant; it merely suggests (wrongly, I think we can agree) that a new prefix for e.g. 1996 unrelated to DE would probably be rejected. We could revise to make clear that we allow dates to be used with unrelated prefixes -- probably a simple change would do:

"Requests to add a prefix to a non-date variant subtag that imply a different semantic meaning will probably be rejected. (This would be permitted when appropriate for four-digit variant subtags representing dates.) ... "

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

---

From: Addison Phillips <[email-masked]>
Date: Tue, 05 Sep 2006 11:04:46 -0700

> The portion you quoted doesn't appear to prevent us from specifying 
 > multiple prefixes for a date variant; it merely suggests (wrongly,
 > I think we can agree) that a new prefix for e.g. 1996 unrelated
 > to DE would probably be rejected. We could revise to make clear
 > that we allow dates to be used with unrelated prefixes --
 > probably a simple change would do:
> 
> "Requests to add a prefix to a non-date variant subtag that 
 > imply a different semantic meaning will probably be
 > rejected. (This would be permitted when appropriate for
 > four-digit variant subtags representing dates.) ... "

-1

"Date variants" are not defined anywhere and I don't believe we should 
get into the business of defining them. We need to deal with the problem 
of adding a prefix to a variant.

I think the correct response to our problems here, as Mark pointed out, 
is to REMOVE the validation requirement of checking the variant prefix. 
Checking the prefix fundamentally means that no prefix can be added to a 
variant in the future (since existing validating tag processors will 
reject the new tags). That is bad. This change would reduce variant 
prefixes to their intended behavior (which is informative).

"Date" variants, like any other semi-generic variant, can therefore 
acquire new prefixes. I think there are shades of "redefining meaning" 
that are being advised against above (and note that the text says that 
the redefinition will "probably" be rejected, not a guarantee or 
requirement that it be rejected).

"nedis" is a case where another prefix can never be warranted: no other 
language is going to have a Nadiza dialect. "1901" is a case where 
another language *could* have an "orthography of 1901". "western" is a 
case where another language *could* have a "Western dialect". But these 
don't change the "meaning" of the subtags--the meaning of the tag they 
appear in is different, though.

This is not new. Consider the tags "nl-BE" and "fr-BE". The subtag 'BE' 
means the same thing in both: the country of Belgium. But the dialects 
defined by either is fundamentally different (the Belgian dialect of 
Dutch is not the same thing as nor does it bear the quite same 
relationship to the parent language as does the Belgian dialect of French).

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.

---

From: John Cowan <[email-masked]>
Date: Wed, 6 Sep 2006 10:18:04 -0400

> is to REMOVE the validation requirement of checking the variant prefix. 

+1

-- 
No,  John.  I want formats that are actually       John Cowan
useful, rather than over-featured megaliths that   http://www.ccil.org/~cowan
address all questions by piling on ridiculous      [email-masked]
internal links in forms which are hideously
over-complex. --Simon St. Laurent on xml-dev

---

From: "Kent Karlsson" <[email-masked]>
Date: Wed, 6 Sep 2006 20:19:14 +0200

> > is to REMOVE the validation requirement of checking the 

I don't understand.

ANY new subtag will be "flagged" by a validating language tag processor
that has not been updated to include the new subtag. The same would
go for newly registered prefix(es) for already existing variant
subtag(s)
and a validating language tag processor that has not been updated
to include the new prefix(es).

If the "validation requirement of checking the variant prefix"
is removed, why not remove also the "validation requirement
of checking the subtag registration". (Which would make validation
rather pointless, since there would be no validation...)

I may have missed something, but did anyone (e.g. Mark) actually
suggest removing the prefix validation (for validating language
tag processors)?

	/kent k

---

From: Peter Constable <[email-masked]>
Date: Wed, 6 Sep 2006 20:40:25 -0700

> From: Kent Karlsson [mailto:[email-masked]]

> that has not been updated to include the new subtag.

I was thinking the same thing.

Peter Constable

---

From: Addison Phillips <[email-masked]>
Date: Wed, 06 Sep 2006 21:09:59 -0700

> I was thinking the same thing.

For entirely unknown subtags, yes. But... with validation currently 
requiring prefix checking, adding a prefix causes existing parsers to 
reject known subtags.

Rejecting an unknown subtag is one thing. Rejecting an unknown prefix 
for a known subtag is something else. If we want to support generic 
variant subtags, the prefix is *informative* information about what that 
subtag means in a given context. So rejecting a subtag for using an 
unknown prefix is undesirable behavior, from a stability point of view.

The alternative is that the prefixes are normative and two validating 
parsers with different dates will produce different results. That is, 
the parser pre-new-prefix rejects tags validated by a parser 
post-new-prefix.

Addison

---

From: Peter Constable <[email-masked]>
Date: Thu, 7 Sep 2006 09:27:51 -0700

> From: Addison Phillips [mailto:[email-masked]]

> requiring prefix checking, adding a prefix causes existing parsers to

But it seems to me we're talking about *tag* validation, not *subtag*
validation, yet your response pertains to subtag validation. If that was
the issue, then all that matters is whether the subtag is known. But
because we're talking about tag validation, while the subtag may be
known the particular usage -- the entire tag -- is not. And rejection in
that case is no different than rejecting usage of a tag due to an
unknown subtag.

Peter Constable

---

From: Addison Phillips <[email-masked]>
Date: Thu, 07 Sep 2006 09:57:08 -0700

> that case is no different than rejecting usage of a tag due to an

If we were to create a true generic variant, the later registration of a 
prefix for that variant would potentially invalidate tags that had 
previously been valid. That's the hypothetical case we'd be fixing.

Addison

---

From: Peter Constable <[email-masked]>
Date: Thu, 7 Sep 2006 13:30:02 -0700

> previously been valid. That's the hypothetical case we'd be fixing.

Eh?

Suppose at T1 "western" is registered with one prefix, "hy". Thus at T1

	hy-western = good
	en-western = bad

Then at T2 > T1 "western" is updated to add a second prefix, "en". So

	post-T2 validator:
	hy-western = good
	en-western = good

	pre-T2 validator:
	hy-western = good
	en-western = bad

So?

Peter Constable

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 07 Sep 2006 23:20:25 +0200

Peter Constable wrote:

>> If we were to create a true generic variant
                          ^^^^^^^^^^^^
> So?

No, your example was "pseudo-generic":  Addison (apparently)
discussed true generic variants:  Mark had explained here why
the 3066bis rules won't allow to downgrade "true generic" to
"pseudo-generic":

At T1 all what-Ever-generic were allowed.  And at T2 after T1
they must be still allowed (= at worst deprecated).  Mark
proposed that we make that clearer in 3066ter, because it's
not obvious.  Others proposed that we could just replace one
critical SHOULD by MUST to eliminate the possibility of any
"true generic" variants.  

Folks insisting on it can still create an extension registry
for their generic purposes.

Frank

---

From: Addison Phillips <[email-masked]>
Date: Thu, 07 Sep 2006 14:39:25 -0700

Suppose at T1 "western" is registered with *NO" prefix (i.e. my "true 
generic"). At T1:

   en-western = good
   hy-western = good

At T2, add prefix "hy":

   en-western = bad   // argh!
   hy-western = good

This violates the idea that once a tag is valid, it is always valid.

QED.

Addison

---

From: Peter Constable <[email-masked]>
Date: Thu, 7 Sep 2006 15:15:53 -0700

> Suppose at T1 "western" is registered with *NO" prefix (i.e. my "true

Ah! Well, we long ago concluded that a true generic couldn't get it's
usage restricted, right? So once a *true* generic always a true generic.
But a true generic doesn't have any prefixes specified. (IIRC that was
the whole point of a thread discussed a couple of weeks ago.)

Peter Constable