Subject: Re: [Ltru] section 3.5 and descriptions...

From: "Doug Ewell" <[email-masked]>
Date: Thu, 10 Jul 2008 19:07:22 -0600

"Phillips, Addison" <addison at amazon dot com> wrote:

> --
> particular language. Each 'Description' field MUST be unique for a 
> given record type. (uniqueness will probably be broadened pending 
> other discussion)
> --
>
> That does say "for a given record *type*". I can't see us broadening 
> uniqueness to the whole registry.
>
> For example, 'he', 'iw', and 'Hebr' all have the Description "Hebrew".

No, there is no need to enforce uniqueness across record types.  There 
is a big difference IMHO between having two languages in the Registry 
called Awa, such that it is impossible to tell which subtag to use (one 
Awa is spoken in China, the other in Papua New Guinea), and having a 
language and a script both called Hebrew.  Nobody who knows how to use 
the Registry correctly (Step 1: look at the Type field) should confuse 
these two.

> Given our new rules, 'iw' would need to acquire a new Description, but 
> I don't see forcing 'Hebr' to have a Description of "Hebrew (script)" 
> as necessary. Ditto 'ar' and 'Arab'---and I'm sure more that I don't 
> know off hand.

Again I didn't read Addison's draft fully.  Deprecated subtags should 
not be part of the uniqueness constraints, certainly not deprecated 
subtags that have a Preferred-Value.  While there is bound to be 
confusion between Awa (awb) and Awa (vwa) because they mean two 
different things, there is no confusion between Hebrew (he) and Hebrew 
(iw) precisely because they mean the same thing, and to prove this, one 
has a Preferred-Value of the other.

Please edit Section 3.1.4 (I think this is the only affected passage) to 
exclude deprecated subtags from the problem space.

--
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: "Mark Davis" <[email-masked]>
Date: Thu, 10 Jul 2008 18:23:06 -0700

Agreed.

Mark

On Thu, Jul 10, 2008 at 6:07 PM, Doug Ewell <[email-masked]> wrote:

>> particular language. Each 'Description' field MUST be unique for a given
>> record type. (uniqueness will probably be broadened pending other
>> discussion)
>> --
>>
> No, there is no need to enforce uniqueness across record types.  There is a
> big difference IMHO between having two languages in the Registry called Awa,
> such that it is impossible to tell which subtag to use (one Awa is spoken in
> China, the other in Papua New Guinea), and having a language and a script
> both called Hebrew.  Nobody who knows how to use the Registry correctly
> (Step 1: look at the Type field) should confuse these two.
>
>  Given our new rules, 'iw' would need to acquire a new Description, but I
>> don't see forcing 'Hebr' to have a Description of "Hebrew (script)" as
>> necessary. Ditto 'ar' and 'Arab'---and I'm sure more that I don't know off
>> hand.
>>
>
> Again I didn't read Addison's draft fully.  Deprecated subtags should not
> be part of the uniqueness constraints, certainly not deprecated subtags that
> have a Preferred-Value.  While there is bound to be confusion between Awa
> (awb) and Awa (vwa) because they mean two different things, there is no
> confusion between Hebrew (he) and Hebrew (iw) precisely because they mean
> the same thing, and to prove this, one has a Preferred-Value of the other.
>

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 10 Jul 2008 20:19:49 -0700

> subtags that have a Preferred-Value.

Yes, but...

Not all subtags start life deprecated. The uniqueness constraint, quite reasonably, tries to fit into a single, declarative sentence:

  'Description' fields assigned to record of any
  specific type ('language', 'extlang', 'script',
  and so on)  MUST be unique within that given record
  type so that users do not become confused about which
  subtag to use.

> While there is bound to be

Agreed. I guess I should add Even More Text allowing some exceptions to the no duplicates rule.

> exclude deprecated subtags from the problem space.

No, at least Section 3.5 is also affected.

Addison

---

From: "Doug Ewell" <[email-masked]>
Date: Thu, 10 Jul 2008 21:58:01 -0600

"Phillips, Addison" <addison at amazon dot com> wrote:

> Not all subtags start life deprecated.

Certainly true.  Deprecation of a subtag that once caused a uniqueness 
problem might make the problem go away.  Since ietf-languages has the 
power to add, change, or delete Description fields (provided they are 
responsible about it; see draft-4646bis-16 §3.4 item 3), they could 
decide to take a Description that was changed to enforce uniqueness and 
revert it to its original ISO name upon deprecation.  Best of all, this 
is authorized by existing text, so you don't have to add anything.

> The uniqueness constraint, quite reasonably, tries to fit into a 
> single, declarative sentence:
>
>  'Description' fields assigned to record of any specific type 
> ('language', 'extlang', 'script', and so on)  MUST be unique within 
> that given record type so that users do not become confused about 
> which subtag to use.

I know the text is too long already, but you really need to add "a" 
after "assigned to".  :-)

>> While there is bound to be confusion between Awa (awb) and Awa (vwa) 
>> because they mean two different things, there is no confusion between 
>> Hebrew (he) and Hebrew (iw) precisely because they mean the same 
>> thing, and to prove this, one has a Preferred-Value of the other.
>

I'm sensitive to the length problem.  The longer the text is, the harder 
it will be to assume that tag users have read it.  I hope we can resolve 
this by simply making it "assigned to a non-deprecated record of any 
specific type" and hoping it isn't necessary to explain in the ensuing 
text why deprecated subtags are exempt.

>> Please edit Section 3.1.4 (I think this is the only affected passage) 
>> to exclude deprecated subtags from the problem space.
>

I guess it's not even safe to assume *I've* read it.  Arrggh.

---

From: "Phillips, Addison" <[email-masked]>
Date: Fri, 11 Jul 2008 13:51:04 -0700

(editor hat)

> I know the text is too long already, but you really need to add "a"

DONE.

> I hope we can
> resolve

I took your suggestion and Peter's suggestion of:

----------------
Each 'Description' field MUST be unique within a given record. Also, each 'Description' field must be unique across the collection of records of the same type with the following exception: if a particular 'Description' field occurs in multiple records of a given type, then one of those records MUST be for a subtag listed in all the other records as Preferred-Value.
----------------

.. and did even more editing to allow duplicates in the excepted case. The paragraphs in 3.1.4 now read:

<t>To help ensure that users do not become confused about which subtag to use, 'Description' fields assigned to a record of any specific type ('language', 'extlang', 'script', and so on)  MUST be unique within that given record type with the following exception: if a particular 'Description' field occurs in multiple records of a given type, then one of those records MUST be for a subtag listed in all the other records as Preferred-Value. This means that two records of the same type that share a 'Description' are also semantically equivalent. </t>

<t>For example, consider the 'language' subtags 'zza' (Zaza) and 'diq' (Dimli). It so happens that 'zza' is a macrolanguage enclosing 'diq' and thus also has a description in ISO 639-3 of "Dimli". This description was edited to read "Dimli (macrolanguage)" in the registry record for 'zza' to prevent a collision.</t>

<t>By contrast, the subtags 'he' and 'iw' share a 'Description' value of "Hebrew"; this is permitted because 'iw' is deprecated and its 'Preferred-Value' is 'he'.</t>

Now, close readers will notice that the instructions to the LSR are missing. That's because they don't make as much sense in the section describing the field as they do in Section 3.5, where the registration procedure is given. By moving the MUSTard directed at the LSR to the registration section, we have a better organization of stuff. The Description text in Section 3.5 now reads:

<t>The 'Description' fields provided in the request MUST contain at least one description written or transcribed into the Latin script; the request MAY also include additional 'Description' fields in any script or language. The 'Description' field is used for identification purposes and doesn't necessarily represent the actual native name of the language or variation. It also doesn't have to be in any particular language, but SHOULD be both suitable and sufficient to identify the item in the record. The Language Subtag Reviewer will check and edit any proposed 'Description' fields so as to ensure uniqueness and prevent collisions with 'Description' fields in other records of the same type. If this occurs in an independent registration request, the Language Subtag Reviewer MUST resubmit the record to ietf-languages, treating it as a modification of a request due to discussion, as described in <xref target="registrationProc"></xref>, unless the request's sole purpose is to introduce a duplicate 'Description' field, in which case the request SHALL be rejected.</t>

<t>While the 'Description' field itself is not guaranteed to be stable and errata corrections MAY be undertaken from time to time, attempts to provide translations or transcriptions of entries in the registry itself will probably be frowned upon by the community or rejected outright, as changes of this nature have an impact on the provisions in <xref target="ianastability"/>.</t>

Addison

---

From: "Mark Davis" <[email-masked]>
Date: Fri, 11 Jul 2008 13:58:30 -0700

Looks great.

Mark

On Fri, Jul 11, 2008 at 1:51 PM, Phillips, Addison <[email-masked]>
wrote:

> Each 'Description' field MUST be unique within a given record. Also, each
> 'Description' field must be unique across the collection of records of the
> same type with the following exception: if a particular 'Description' field
> occurs in multiple records of a given type, then one of those records MUST
> be for a subtag listed in all the other records as Preferred-Value.
> ----------------
>
> <t>To help ensure that users do not become confused about which subtag to
> use, 'Description' fields assigned to a record of any specific type
> ('language', 'extlang', 'script', and so on)  MUST be unique within that
> given record type with the following exception: if a particular
> 'Description' field occurs in multiple records of a given type, then one of
> those records MUST be for a subtag listed in all the other records as
> Preferred-Value. This means that two records of the same type that share a
> 'Description' are also semantically equivalent. </t>
>
> <t>For example, consider the 'language' subtags 'zza' (Zaza) and 'diq'
> (Dimli). It so happens that 'zza' is a macrolanguage enclosing 'diq' and
> thus also has a description in ISO 639-3 of "Dimli". This description was
> edited to read "Dimli (macrolanguage)" in the registry record for 'zza' to
> prevent a collision.</t>
>
> <t>By contrast, the subtags 'he' and 'iw' share a 'Description' value of
> "Hebrew"; this is permitted because 'iw' is deprecated and its
> 'Preferred-Value' is 'he'.</t>
>
> Now, close readers will notice that the instructions to the LSR are
> missing. That's because they don't make as much sense in the section
> describing the field as they do in Section 3.5, where the registration
> procedure is given. By moving the MUSTard directed at the LSR to the
> registration section, we have a better organization of stuff. The
> Description text in Section 3.5 now reads:
>
> <t>The 'Description' fields provided in the request MUST contain at least
> one description written or transcribed into the Latin script; the request
> MAY also include additional 'Description' fields in any script or language.
> The 'Description' field is used for identification purposes and doesn't
> necessarily represent the actual native name of the language or variation.
> It also doesn't have to be in any particular language, but SHOULD be both
> suitable and sufficient to identify the item in the record. The Language
> Subtag Reviewer will check and edit any proposed 'Description' fields so as
> to ensure uniqueness and prevent collisions with 'Description' fields in
> other records of the same type. If this occurs in an independent
> registration request, the Language Subtag Reviewer MUST resubmit the record
> to ietf-languages, treating it as a modification of a request due to
> discussion, as described in <xref target="registrationProc"></xref>, unless
> the request's sole purpose is to intr
>  oduce a duplicate 'Description' field, in which case the request SHALL be
> rejected.</t>
>
> <t>While the 'Description' field itself is not guaranteed to be stable and
> errata corrections MAY be undertaken from time to time, attempts to provide
> translations or transcriptions of entries in the registry itself will
> probably be frowned upon by the community or rejected outright, as changes
> of this nature have an impact on the provisions in <xref
> target="ianastability"/>.</t>
>
>
>
> Addison