Subject: RE: [Ltru] At least one prefix for variant (GenArt)

From: "Addison Phillips" <[email-masked]>
Date: Thu, 1 Sep 2005 09:10:15 -0700

> John Cowan wrote:
> 
> > | Variant registration requests are REQUIRED to include at
> > | least one "Prefix" field in the registration form.
> >
> > Is it that what you're looking for ?  Bye, Frank
> 
> I forgot about this.  Do we really want to forbid variants that apply
> to every language?  "signed" would be a reasonable such candidate;
> it can be applied to any spoken language to specify the (exact)
> signed equivalent: thus en-signed would be a mapping from English
> to signs.  This is not the same as sign languages proper.
> 
[Addison Phillips] 

We did debate this previously. The question was whether the community could make judgments about generic subtags, either for acceptance or application of them. Requiring at least one prefix effectively limits variants to the description of particular language variations.

There is a way to fix this without removing the requirement. Currently the text in "Prefix" in S3.1 says:

--
Prefix's field-value contains a language tag with which this subtag MAY be used to form a new language tag, perhaps with other subtags as well. This field MUST only appear in records whose 'Type' field-value is 'variant' or 'extlang'. For example, the 'Prefix' for the variant 'nedis' is 'sl', meaning that the tags "sl-nedis" and "sl-IT-nedis" might be appropriate while the tag "is-nedis" is not.
--

What it should actually say is "Prefix's field-value contains a language RANGE".

This is more correct (it is actually what it means) and also would allow a generic subtag to be registered, using the generic language range "*". It would also allow very specialized subtags. Consider:

Subtag: hankaku
Prefix: *-Kana

The problem here, of course, is that "range" is a "matching" beast.

Addison

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

---

From: "John.Cowan" <[email-masked]>
Date: Thu, 1 Sep 2005 12:58:23 -0400

Addison Phillips scripsit:

> We did debate this previously. The question was whether the community
> could make judgments about generic subtags, either for acceptance or
> application of them. Requiring at least one prefix effectively limits
> variants to the description of particular language variations.

Indeed.

> There is a way to fix this without removing the requirement. 

[snip]

> The problem here, of course, is that "range" is a "matching" beast.

I think that makes the cure worse than the disease.  "Prefix: *" is just a
verbose way of saying "no prefix required".

I request (as part of Last Call) that this be reconsidered by the WG.
Variants without prefixes may require heightened scrutiny by ietf-languages
and the LSR, but I do not think they should be forbidden altogether.

-- 
John Cowan                                [email-masked]
At times of peril or dubitation,          http://www.ccil.org/~cowan
Perform swift circular ambulation,        http://www.reutershealth.com
With loud and high-pitched ululation.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 01 Sep 2005 22:08:48 +0200

> I request (as part of Last Call) that this be reconsidered

You tested the idea of generic variants on the review list
(among others -north, -east, -west, -south, and what I recall
 as -familiar, but that wasn't your proposal)

The result of this discussion was "bad idea" (okay, I wasn't
sure that it's necessarily bad, I said "utter dubious" for
your old examples).
                           Bye, Frank

---

From: r&d afrac <[email-masked]>
Date: Fri, 02 Sep 2005 14:21:49 +0200

>sure that it's necessarily bad, I said "utter dubious" for

John has no problem in using an x-tag.

en-x-east.

Happily there is no private use return singleton, like say "u-". We 
would have a "en-x-east-u-Latn-us" mess....
But he can have "en-Latn-us-x-east.

I note that Mark wants to be able to support en-189-us? Would that be 
for voice subtags? Would be an interesting move.
jfc

---

From: Mark Davis <[email-masked]>
Date: Fri, 02 Sep 2005 09:48:28 -0700

> for voice subtags? Would be an interesting move.

Incorrect. I was suggesting reserving certain subtags for future use as 
either scripts/orthographies or regions. But "en-189-us" doesn't match 
what I said; look at the ABNF:

- scripts would always be 4 characters, and
- regions would always be 2 or 3 characters.

So your example is invalid under both the current proposal and under my 
suggested addition of reservations for the future, since your example 
has 2 region codes in a row.

More realistic examples would be:

el-Ply0-GR // Ply0 is an example of a possible future use, e.g. polytonic

or

en-PR0 // US2 is an example of a possible future use, e.g. a historic 
region like Prussia

Frankly (or Ellermanly), regions are not that interesting, because 
variants are adjacent in the tags, and thus would have the right 
fallback behavior.

However, script/orthographies are interesting, since they *can't* be 
replaced by variants in fallback; you get the wrong answer.

Mark

---

From: r&d afrac <[email-masked]>
Date: Sat, 03 Sep 2005 05:57:17 +0200

At 18:48 02/09/2005, Mark Davis wrote:
>Incorrect. I was suggesting reserving certain subtags for future use 
>as either scripts/orthographies or regions. But "en-189-us" doesn't 
>match what I said; look at the ABNF:

Dear Mark,
correct. I misread the proposition.

>So your example is invalid under both the current proposal and under 
>my suggested addition of reservations for the future, since your 
>example has 2 region codes in a row.
>en-PR0 // US2 is an example of a possible future use, e.g. a 
>historic region like Prussia
>

So, you still do not want to document the multimodal aspects? This 
keeps the draft in the ISO 639 script oriented "mood" I would say? Up 
to now Addison and you responded quickly to protect the ABNF against 
my propositions. It lead to a far better clarity than in Dec last, 
and reduced the risks of conflicts with the URI-tags. Does that mean 
that you abandon us the voice/sign/icon.. documentation?

I have no problem with that, but our MPEG liaison would like to know.
Take care.
jfc

jfc