Subject: [Ltru] 3.1.4: description field uniqueness

From: Peter Constable <[email-masked]>
Date: Mon, 7 Jul 2008 21:12:05 -0700

Section 3.1.4 of the current draft has this wording:

----------------
Each 'Description' field MUST be unique, both within the record in which it appears and for the collection of records of the same type.
----------------

I'm not positive I understand the intent for the second requirement, unique "for the collection of records of the same type". It sounds like that's saying that, if (say) a language record has a description field with the value "foo", then no other language record can have a description "foo".

If that's the case, then what about cases such as the records for the language subtags 'jv' and 'jw', both of which have a description "Javanese"?

Would the following revised text be an improvement?

----------------
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.
----------------

I think that covers the Javanese, Hebrew and such cases.

(I still hope we don't one day down the road find it overly restrictive should, e.g., two 639-2 entries each have multiple language names, one of which is common to both.)

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

---

From: "Mark Davis" <[email-masked]>
Date: Mon, 7 Jul 2008 21:13:53 -0700

+1

Mark

On Mon, Jul 7, 2008 at 9:12 PM, Peter Constable <[email-masked]>
wrote:

> Each 'Description' field MUST be unique, both within the record in which it
> appears and for the collection of records of the same type.
> ----------------
>
> I'm not positive I understand the intent for the second requirement, unique
> "for the collection of records of the same type". It sounds like that's
> saying that, if (say) a language record has a description field with the
> value "foo", then no other language record can have a description "foo".
>
> If that's the case, then what about cases such as the records for the
> language subtags 'jv' and 'jw', both of which have a description "Javanese"?
>
> 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.
> ----------------
>
> (I still hope we don't one day down the road find it overly restrictive
> should, e.g., two 639-2 entries each have multiple language names, one of
> which is common to both.)
>
>
>
> Peter

---

From: John Cowan <[email-masked]>
Date: Tue, 8 Jul 2008 01:00:53 -0400

Peter Constable scripsit:

> 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.

I'd rather just abandon the restriction altogether and leave it up to
the common sense of ietf-languages.

-- 
John Cowan    http://ccil.org/~cowan    [email-masked]
[T]here is a Darwinian explanation for the refusal to accept Darwin.
Given the very pessimistic conclusions about moral purpose to which his
theory drives us, and given the importance of a sense of moral purpose
in helping us cope with life, a refusal to believe Darwin's theory may
have important survival value. --Ian Johnston
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 8 Jul 2008 08:13:51 -0700

+1

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of John Cowan
> Sent: Monday, July 07, 2008 10:01 PM
> To: Peter Constable
> Cc: LTRU Working Group
> Subject: Re: [Ltru] 3.1.4: description field uniqueness
>

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 8 Jul 2008 10:33:38 -0700

(technical hat)

I agree... but this was done on purpose (the purpose of which appears later in the paragraph).

(editor hat)

I removed the overall uniqueness requirement, narrowing it to within a record and focusing on formatting variations.

--
<t>The field 'Description' contains a description of the tag or subtag in the record. The 'Description' field MAY appear more than once per record, that is, there can be multiple descriptions for a given record. The 'Description' field MAY include the full range of Unicode characters. At least one of the 'Description' fields MUST be written or transcribed into the Latin script; additional 'Description' fields MAY also include descriptions in non-Latin scripts. Each 'Description' field SHOULD be unique within the record in which it appears and formatting variations of the same description SHOULD NOT occur in that specific record. For example, while the ISO 639-1 code 'fy' contains both the descriptions "Western Frisian" and "Frisian, Western", only one of these descriptions appears in the registry.</t>
--

Addison Phillips

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 8 Jul 2008 10:48:58 -0700

I disagree with this change. The descriptions need to be unique within the
type of field. We can always qualify the names, eg "Ainu (China)".

Mark

On Tue, Jul 8, 2008 at 10:33 AM, Phillips, Addison <[email-masked]>
wrote:

> I removed the overall uniqueness requirement, narrowing it to within a
> record and focusing on formatting variations.
>
> --
> <t>The field 'Description' contains a description of the tag or subtag in
> the record. The 'Description' field MAY appear more than once per record,
> that is, there can be multiple descriptions for a given record. The
> 'Description' field MAY include the full range of Unicode characters. At
> least one of the 'Description' fields MUST be written or transcribed into
> the Latin script; additional 'Description' fields MAY also include
> descriptions in non-Latin scripts. Each 'Description' field SHOULD be unique
> within the record in which it appears and formatting variations of the same
> description SHOULD NOT occur in that specific record. For example, while the
> ISO 639-1 code 'fy' contains both the descriptions "Western Frisian" and
> "Frisian, Western", only one of these descriptions appears in the
> registry.</t>
> --
>
> Addison Phillips
> > John Cowan    http://ccil.org/~cowan <http://ccil.org/%7Ecowan>
> [email-masked]

---

From: Peter Constable <[email-masked]>
Date: Tue, 8 Jul 2008 12:29:48 -0700

The collective set of descriptions for a given record should be unique across records of a given type (modulo cases like Javanese). Doug has pointed out an existing instance (“Dimli”) in which a single description field can’t be unique across all descriptions for all records of a given type.

Peter

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Davis
Sent: Tuesday, July 08, 2008 10:49 AM
To: Phillips, Addison
Cc: John Cowan; Peter Constable; LTRU Working Group
Subject: Re: [Ltru] 3.1.4: description field uniqueness

I disagree with this change. The descriptions need to be unique within the type of field. We can always qualify the names, eg "Ainu (China)".

Mark
On Tue, Jul 8, 2008 at 10:33 AM, Phillips, Addison <[email-masked]<mailto:[email-masked]>> wrote:
(technical hat)

(editor hat)

Addison Phillips

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
> Behalf Of John Cowan
> John Cowan    http://ccil.org/~cowan<http://ccil.org/%7Ecowan>    [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
Ltru mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 8 Jul 2008 13:34:21 -0700

It certainly *can* be made to be unique across all records, without
resorting to rocket science: change zza's Dimli by adding an annotation,
like "Dimli (Zaza)".

http://www.sil.org/iso639-3/documentation.asp?id=zza
http://www.sil.org/iso639-3/documentation.asp?id=diq

Mark

On Tue, Jul 8, 2008 at 12:29 PM, Peter Constable <[email-masked]>
wrote:

>  The collective set of descriptions for a given record should be unique
> across records of a given type (modulo cases like Javanese). Doug has
> pointed out an existing instance ("Dimli") in which a single description
> field can't be unique across all descriptions for all records of a given
> type.
>
>
>
>
>
> Peter
>
>
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Mark Davis
> *Sent:* Tuesday, July 08, 2008 10:49 AM
> *To:* Phillips, Addison
> *Cc:* John Cowan; Peter Constable; LTRU Working Group
>
> *Subject:* Re: [Ltru] 3.1.4: description field uniqueness
>
>
>

---

From: Peter Constable <[email-masked]>
Date: Tue, 8 Jul 2008 14:00:17 -0700

The problem is that, as things stand, we would be dependent on ISO 639 RAs / JAC to set names in such a way as to ensure that uniqueness guarantee, and whereas we divide the alternate names for a given entry into separate description fields they just have a single “name” field – ie., they would have to ensure that no single name was ever used in more than one entry, a uniqueness guarantee that goes far beyond what they require. Clearly, that’s not a reasonable expectation. If we wanted to maintain this level of uniquess, then our only option would be to add text in 3.4 allowing the Reviewer to edit names coming from a source ISO standard by adding parenthetic qualifiers to ensure uniqueness.

But it’s not clear to me why we would really need *that* level of uniqueness.

Peter

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Davis
Sent: Tuesday, July 08, 2008 1:34 PM
To: Peter Constable
Cc: LTRU Working Group
Subject: Re: [Ltru] 3.1.4: description field uniqueness

It certainly can be made to be unique across all records, without resorting to rocket science: change zza's Dimli by adding an annotation, like "Dimli (Zaza)".

Mark
On Tue, Jul 8, 2008 at 12:29 PM, Peter Constable <[email-masked]<mailto:[email-masked]>> wrote:

The collective set of descriptions for a given record should be unique across records of a given type (modulo cases like Javanese). Doug has pointed out an existing instance ("Dimli") in which a single description field can't be unique across all descriptions for all records of a given type.

Peter

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Mark Davis
Sent: Tuesday, July 08, 2008 10:49 AM
To: Phillips, Addison
Cc: John Cowan; Peter Constable; LTRU Working Group

Mark

(technical hat)

(editor hat)

Addison Phillips

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 8 Jul 2008 14:18:18 -0700

When we show a list of items in a menu for users to pick, we need to have
uniqueness. We don't want to list "Congo" twice for countries, and we don't
want to list "Dimli" twice for two different language codes. Moreover, it is
just common sense to add clarifications where we have duplicates, as is
already done for Ainu and other languages.

So I think the correct change is not to change the uniqueness clause, but
instead to change the following to be clearer about the requirements.

When creating or updating a record due to the action of one of the source
standards, the Language Subtag Reviewer SHOULD remove duplicate or redundant
descriptions and MAY edit descriptions to correct irregularities in
formatting (such as misspellings, inappropriate apostrophes or other
punctuation, or excessive or missing spaces) prior to submitting the
proposed record to the ietf-languages list.
=>
When creating or updating a record, prior to submitting the proposed record
to the ietf-languages list the Language Subtag Reviewer MUST add annotations
(in parentheses) if necessary to preserve the uniqueness of descriptions,
SHOULD remove duplicate or redundant descriptions, and MAY edit descriptions
to correct irregularities in formatting (such as misspellings, inappropriate
apostrophes or other punctuation, or excessive or missing spaces).

Mark

On Tue, Jul 8, 2008 at 2:00 PM, Peter Constable <[email-masked]>
wrote:

>  The problem is that, as things stand, we would be dependent on ISO 639
> RAs / JAC to set names in such a way as to ensure that uniqueness guarantee,
> and whereas we divide the alternate names for a given entry into separate
> description fields they just have a single "name" field – ie., they would
> have to ensure that no single name was ever used in more than one entry, a
> uniqueness guarantee that goes far beyond what they require. Clearly, that's
> not a reasonable expectation. If we wanted to maintain this level of
> uniquess, then our only option would be to add text in 3.4 allowing the
> Reviewer to edit names coming from a source ISO standard by adding
> parenthetic qualifiers to ensure uniqueness.
>
>
>
> But it's not clear to me why we would really need **that** level of
> uniqueness.
>
>
>
>
>
> Peter
>
>
>
> *Sent:* Tuesday, July 08, 2008 1:34 PM
>
> *To:* Peter Constable
> *Cc:* LTRU Working Group

---

From: Peter Constable <[email-masked]>
Date: Tue, 8 Jul 2008 14:28:11 -0700

Hmmm… I thought we weren’t intending to be providing UI strings. Certainly 3.1.4 states that we don’t guarantee the names to be in any particular language, and it seems to indicate that the only purpose of descriptions is to differentiate between subtags (though it doesn’t make clear whether every description field, alone, should be sufficient for that purpose).

At any rate, I’m not opposed to making this kind of change. It means a bit more work for the Reviewer, and could lead to cases in which a change in one entry in a source ISO standard leads to updates to multiple records in the LSTR.

Peter

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Davis
Sent: Tuesday, July 08, 2008 2:18 PM
To: Peter Constable
Cc: LTRU Working Group
Subject: Re: [Ltru] 3.1.4: description field uniqueness

When we show a list of items in a menu for users to pick, we need to have uniqueness. We don't want to list "Congo" twice for countries, and we don't want to list "Dimli" twice for two different language codes. Moreover, it is just common sense to add clarifications where we have duplicates, as is already done for Ainu and other languages.

So I think the correct change is not to change the uniqueness clause, but instead to change the following to be clearer about the requirements.
When creating or updating a record due to the action of one of the source standards, the Language Subtag Reviewer SHOULD remove duplicate or redundant descriptions and MAY edit descriptions to correct irregularities in formatting (such as misspellings, inappropriate apostrophes or other punctuation, or excessive or missing spaces) prior to submitting the proposed record to the ietf-languages list.
=>
When creating or updating a record, prior to submitting the proposed record to the ietf-languages list the Language Subtag Reviewer MUST add annotations (in parentheses) if necessary to preserve the uniqueness of descriptions, SHOULD remove duplicate or redundant descriptions, and MAY edit descriptions to correct irregularities in formatting (such as misspellings, inappropriate apostrophes or other punctuation, or excessive or missing spaces).

Mark
On Tue, Jul 8, 2008 at 2:00 PM, Peter Constable <[email-masked]<mailto:[email-masked]>> wrote:

The problem is that, as things stand, we would be dependent on ISO 639 RAs / JAC to set names in such a way as to ensure that uniqueness guarantee, and whereas we divide the alternate names for a given entry into separate description fields they just have a single "name" field – ie., they would have to ensure that no single name was ever used in more than one entry, a uniqueness guarantee that goes far beyond what they require. Clearly, that's not a reasonable expectation. If we wanted to maintain this level of uniquess, then our only option would be to add text in 3.4 allowing the Reviewer to edit names coming from a source ISO standard by adding parenthetic qualifiers to ensure uniqueness.

But it's not clear to me why we would really need *that* level of uniqueness.

Peter

To: Peter Constable
Cc: LTRU Working Group

Mark

Peter

Mark

(technical hat)

(editor hat)

Addison Phillips

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 8 Jul 2008 14:36:49 -0700

We went through this awhile ago, hence all this text about uniqueness. But it does seem, upon further reflection, that it would be a pain to check.

I think it is reasonable to keep the “different formats” prohibition.

I can understand why Mark and others would want descriptions to be unique too: how can users figure out which of the identically named items to use for what? In practice it is probably fairly obvious, provided one knows that, say, Dimli does appear twice and not just once. While it isn’t much work to check it, I wouldn’t be surprised to find something slip through. I think we could accommodate this by SHOULDifying uniqueness (we have already given the LSR broad editorial powers regarding descriptions). Perhaps add a paragraph saying:

<t>Descriptions SHOULD be unique within a given type of subtag so that users do not become confused about which subtag to use and the Language Subtag Reviewer SHOULD edit any that match existing descriptions to ensure clarity. For example, the language subtags 'zza' and 'diq' both have a description in ISO 639-3 of "Dimli". It happens that 'zza' (Zaza) is a macrolanguage that encloses the language 'diq'. Therefore the set of Description fields for 'zza' includes one that was edited to read "Dimli (macrolanguage)".</t>

Addison Phillips

From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Constable
Sent: Tuesday, July 08, 2008 2:00 PM
To: Mark Davis; LTRU Working Group
Subject: Re: [Ltru] 3.1.4: description field uniqueness

Peter

Mark

Peter

Mark

(technical hat)

(editor hat)

Addison Phillips

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 8 Jul 2008 14:38:44 -0700

Well… less the runon sentence…

Addison

Addison Phillips

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phillips, Addison
Sent: Tuesday, July 08, 2008 2:37 PM
To: Peter Constable; Mark Davis; LTRU Working Group
Subject: Re: [Ltru] 3.1.4: description field uniqueness

Addison Phillips

Peter

Mark

Peter

Mark

(technical hat)

(editor hat)

Addison Phillips

---

From: Peter Constable <[email-masked]>
Date: Tue, 8 Jul 2008 15:17:51 -0700

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

> <t>Descriptions SHOULD be unique within a given type of subtag so
> that users do not become confused about which subtag to use and the
> Language Subtag Reviewer SHOULD edit any that match existing
> descriptions to ensure clarity. For example, the language subtags
> 'zza' and 'diq' both have a description in ISO 639-3 of "Dimli"...

I replied to Mark earlier describing the 639 data in a way that isn't quite accurate wrt 639-3: in the main, normative, data file, every ID has an associated reference name, and those are required to be unique. There is also an informative Language Names Index file that lists alternate names for each ID (including the reference name); these names are not guaranteed to be unique.

So, the reality for 639-3 isn't exactly as you describe it, but probably close enough.

Peter

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 8 Jul 2008 17:15:26 -0700

That won't do it. I can live with a MUST on only the first Description; as
Peter said, that should be guaranteed by 639-3, so it should only in extreme
cases where there is a slip-up in a source standard that we have to add an
annotation. So here is suggested text.

<t>The first Descriptions in each of the records are often the basis for
translations of language names. They MUST be unique within a given type of
subtag so that users do not become confused about which subtag to use. The
Language Subtag Reviewer MUST edit any proposed first Descriptions so as to
ensure uniqueness among the first Descriptions (that is, prevent collisions).
The Language Subtag Reviewer SHOULD edit other (non-first) Descriptions to
preserve uniqueness, as well.</t>

<t>For example, consider the language subtags 'zza' and 'diq'. Their first
Descriptions ("Zaza" and "Dimli" respectively) are taken from the ISO 639
reference names, and do not collide. It happens that 'zza' (Zaza) also has a
non-first Description of "Dimli". Although not strictly required, it was
edited to read "Dimli (macrolanguage)" to prevent a collision. If 'zza' had
had a first description of "Dimli", then such editing to prevent a collision
would have been required.</t>

Mark

On Tue, Jul 8, 2008 at 2:36 PM, Phillips, Addison <[email-masked]>
wrote:

>  We went through this awhile ago, hence all this text about uniqueness.
> But it does seem, upon further reflection, that it would be a pain to check.
>
>
>
> I think it is reasonable to keep the "different formats" prohibition.
>
>
>
> I can understand why Mark and others would want descriptions to be unique
> too: how can users figure out which of the identically named items to use
> for what? In practice it is probably fairly obvious, provided one knows
> that, say, Dimli does appear twice and not just once. While it isn't much
> work to check it, I wouldn't be surprised to find something slip through. I
> think we could accommodate this by SHOULDifying uniqueness (we have already
> given the LSR broad editorial powers regarding descriptions). Perhaps add a
> paragraph saying:
>
>
>
> <t>Descriptions SHOULD be unique within a given type of subtag so that
> users do not become confused about which subtag to use and the Language
> Subtag Reviewer SHOULD edit any that match existing descriptions to ensure
> clarity. For example, the language subtags 'zza' and 'diq' both have a
> description in ISO 639-3 of "Dimli". It happens that 'zza' (Zaza) is a
> macrolanguage that encloses the language 'diq'. Therefore the set of
> Description fields for 'zza' includes one that was edited to read "Dimli
> (macrolanguage)".</t>
>
>
>
>
>
> Addison Phillips
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Peter Constable
> *Sent:* Tuesday, July 08, 2008 2:00 PM
> *To:* Mark Davis; LTRU Working Group
>
> The problem is that, as things stand, we would be dependent on ISO 639 RAs
> / JAC to set names in such a way as to ensure that uniqueness guarantee, and
> whereas we divide the alternate names for a given entry into separate

---

From: "Phillips, Addison" <[email-masked]>
Date: Wed, 9 Jul 2008 15:16:36 -0700

In incorporating this, I reordered and reworked a number of paragraphs. The problem here is that we jumped back and forth between ISO 639 and general descriptions—and we had several pieces of text that did basically the same thing (give the LSR permission/requirements to edit).

This extensive edit reads:

<section anchor="descriptionfield" title="Description Field">

<t>The field 'Description' contains a description of the tag or subtag in the record. The 'Description' field MAY appear more than once per record. The 'Description' field MAY include the full range of Unicode characters. At least one of the 'Description' fields MUST be written or transcribed into the Latin script; additional 'Description' fields MAY also include descriptions in non-Latin scripts.</t>

<t>The 'Description' field is used for identification purposes. Descriptions SHOULD contain all and only that information necessary
to distinguish one subtag from others that it might be confused with.
They are not intended to provide general background information,
nor to provide all possible alternate names or designations. 'Description' fields don't necessarily represent the actual native name of the item in the record, nor are any of the descriptions guaranteed to be in any particular language (such as English or French, for example).</t>

<t>Descriptions in the registry that correspond to ISO 639, ISO 15924,  ISO 3166-1, or UN M.49 codes are
intended only to indicate the meaning of that identifier as defined in
the source standard at the time it was added to the registry or as subsequently modified, within the bounds of the <xref target="ianastability">stability rules</xref>, via subsequent registration. The 'Description' does not replace the content of the source
standard itself. 'Description' fields are not intended to be the localized English names
for the subtags. Localization or translation of language tag and subtag descriptions is out of scope
of this document.</t>

<t>For subtags taken from a source standard (such as ISO 639 or ISO 15924), the 'Description' fields in the record are also initially taken from that source standard. Multiple descriptions in the source standard are split into separate 'Description' fields. The source standard's descriptions MAY be edited or modified, either prior to insertion or via the registration process, and additional or extraneous descriptions omitted or removed. Each 'Description' field MUST be unique within the record in which it appears and formatting variations of the same description SHOULD NOT occur in that specific record. For example, while the ISO 639-1 code 'fy' has both the description "Western Frisian" and and the description "Frisian, Western" in that standard, only one of these descriptions appears in the registry.</t>

<t>The first 'Description' field 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. The Language Subtag Reviewer MUST edit any proposed first 'Description' fields so as to ensure uniqueness and prevent collisions between the first 'Description' fields of the various record types. The Language Subtag Reviewer SHOULD edit other, non-first, 'Description' fields to preserve uniqueness as well.</t>

<t>For example, consider the 'language' subtags 'zza' and 'diq'. Their ISO 639-3 reference names (and thus, their first 'Description' field) are "Zaza" and "Dimli" respectively, and do not collide. It happens that 'zza' (Zaza) also has a description in ISO 639-3 of "Dimli". Although not strictly required, it was edited to read "Dimli (macrolanguage)" in the registry to prevent a collision. If 'zza' had originally had a reference name of "Dimli", then such editing to prevent a collision would have been required.</t>

<t>For fields of type 'language', the first 'Description' field appearing in the Registry
corresponds whenever possible to the Reference Name assigned by ISO 639-3. This helps facilitate
cross-referencing between ISO 639 and the registry. </t>

<t>When creating or updating a record due to the action of one of the source standards, the Language Subtag Reviewer MAY edit descriptions to correct irregularities in formatting (such as misspellings, inappropriate apostrophes or other punctuation, or excessive or missing spaces) prior to submitting the proposed record to the ietf-languages list for consideration.</t>

</section>

Addison Phillips

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Davis
Sent: Tuesday, July 08, 2008 5:15 PM
To: Phillips, Addison
Cc: Peter Constable; LTRU Working Group
Subject: Re: [Ltru] 3.1.4: description field uniqueness

That won't do it. I can live with a MUST on only the first Description; as Peter said, that should be guaranteed by 639-3, so it should only in extreme cases where there is a slip-up in a source standard that we have to add an annotation. So here is suggested text.

<t>The first Descriptions in each of the records are often the basis for translations of language names. They MUST be unique within a given type of subtag so that users do not become confused about which subtag to use. The Language Subtag Reviewer MUST edit any proposed first Descriptions so as to ensure uniqueness among the first Descriptions (that is, prevent collisions). The Language Subtag Reviewer SHOULD edit other (non-first) Descriptions to preserve uniqueness, as well.</t>

<t>For example, consider the language subtags 'zza' and 'diq'. Their first Descriptions ("Zaza" and "Dimli" respectively) are taken from the ISO 639 reference names, and do not collide. It happens that 'zza' (Zaza) also has a non-first Description of "Dimli". Although not strictly required, it was edited to read "Dimli (macrolanguage)" to prevent a collision. If 'zza' had had a first description of "Dimli", then such editing to prevent a collision would have been required.</t>

Mark
On Tue, Jul 8, 2008 at 2:36 PM, Phillips, Addison <[email-masked]<mailto:[email-masked]>> wrote:

I can understand why Mark and others would want descriptions to be unique too: how can users figure out which of the identically named items to use for what? In practice it is probably fairly obvious, provided one knows that, say, Dimli does appear twice and not just once. While it isn't much work to check it, I wouldn't be surprised to find something slip through. I think we could accommodate this by SHOULDifying uniqueness (we have already given the LSR broad editorial powers regarding descriptions). Perhaps add a paragraph saying:

Addison Phillips

It is an architecture.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Peter Constable
Sent: Tuesday, July 08, 2008 2:00 PM
To: Mark Davis; LTRU Working Group

Peter

Mark

Peter

Mark

(technical hat)

(editor hat)

Addison Phillips

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 9 Jul 2008 15:21:46 -0700

Looks great.

Mark

On Wed, Jul 9, 2008 at 3:16 PM, Phillips, Addison <[email-masked]>
wrote:

>  In incorporating this, I reordered and reworked a number of paragraphs.
> The problem here is that we jumped back and forth between ISO 639 and
> general descriptions—and we had several pieces of text that did basically
> the same thing (give the LSR permission/requirements to edit).
>
>
>
> the record. The 'Description' field MAY appear more than once per record.
> The 'Description' field MAY include the full range of Unicode characters. At
> descriptions in non-Latin scripts.</t>
>
>
>
>
> <t>The 'Description' field is used for identification purposes.
> Descriptions SHOULD contain all and only that information necessary
>
> nor to provide all possible alternate names or designations. 'Description'
> fields don't necessarily represent the actual native name of the item in the
> record, nor are any of the descriptions guaranteed to be in any particular
> language (such as English or French, for example).</t>
>
>
>
>
> the source standard at the time it was added to the registry or as
> subsequently modified, within the bounds of the <xref
> target="ianastability">stability rules</xref>, via subsequent registration.
> The 'Description' does not replace the content of the source
>
> <t>For subtags taken from a source standard (such as ISO 639 or ISO 15924),
> the 'Description' fields in the record are also initially taken from that
> source standard. Multiple descriptions in the source standard are split into
> separate 'Description' fields. The source standard's descriptions MAY be
> edited or modified, either prior to insertion or via the registration
> process, and additional or extraneous descriptions omitted or removed. Each
> 'Description' field MUST be unique within the record in which it appears and
> formatting variations of the same description SHOULD NOT occur in that
> specific record. For example, while the ISO 639-1 code 'fy' has both the
> description "Western Frisian" and and the description "Frisian, Western" in
> that standard, only one of these descriptions appears in the registry.</t>
>
>
>
> <t>The first 'Description' field 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. The Language Subtag Reviewer MUST edit any proposed first 'Description'
> fields so as to ensure uniqueness and prevent collisions between the first
> 'Description' fields of the various record types. The Language Subtag
> Reviewer SHOULD edit other, non-first, 'Description' fields to preserve
> uniqueness as well.</t>
>
>
>
> <t>For example, consider the 'language' subtags 'zza' and 'diq'. Their ISO
> 639-3 reference names (and thus, their first 'Description' field) are "Zaza"
> and "Dimli" respectively, and do not collide. It happens that 'zza' (Zaza)
> also has a description in ISO 639-3 of "Dimli". Although not strictly
> required, it was edited to read "Dimli (macrolanguage)" in the registry to
> prevent a collision. If 'zza' had originally had a reference name of
> "Dimli", then such editing to prevent a collision would have been
> required.</t>
>
>
>
> <t>When creating or updating a record due to the action of one of the
> source standards, the Language Subtag Reviewer MAY edit descriptions to
> correct irregularities in formatting (such as misspellings, inappropriate
> apostrophes or other punctuation, or excessive or missing spaces) prior to
> submitting the proposed record to the ietf-languages list for
> consideration.</t>
>
>
>
>
> </section>
>
>
>
>
>
> Addison Phillips
>
> *Sent:* Tuesday, July 08, 2008 5:15 PM
> *To:* Phillips, Addison
> *Cc:* Peter Constable; LTRU Working Group
>
> ensure uniqueness among the first Descriptions (that is, prevent
> collisions). The Language Subtag Reviewer SHOULD edit other (non-first)
> Descriptions to preserve uniqueness, as well.</t>
>
> We went through this awhile ago, hence all this text about uniqueness. But
> it does seem, upon further reflection, that it would be a pain to check.
>
>
>

---

From: Peter Constable <[email-masked]>
Date: Wed, 9 Jul 2008 21:47:07 -0700

+1

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Davis
Sent: Wednesday, July 09, 2008 3:22 PM
To: Phillips, Addison
Cc: Peter Constable; LTRU Working Group
Subject: Re: [Ltru] 3.1.4: description field uniqueness

Looks great.

Mark
On Wed, Jul 9, 2008 at 3:16 PM, Phillips, Addison <[email-masked]<mailto:[email-masked]>> wrote:

of this document.</t>

</section>

Addison Phillips

It is an architecture.

Mark

Addison Phillips

It is an architecture.

Peter

Mark

Peter

Mark

(technical hat)

(editor hat)

Addison Phillips

---

From: "Mark Davis" <[email-masked]>
Date: Thu, 10 Jul 2008 09:59:42 -0700

+1

Mark

On Wed, Jul 9, 2008 at 9:47 PM, Peter Constable <[email-masked]>
wrote:

> *Sent:* Wednesday, July 09, 2008 3:22 PM
>
> *To:* Phillips, Addison
> In incorporating this, I reordered and reworked a number of paragraphs. The
> problem here is that we jumped back and forth between ISO 639 and general
> descriptions—and we had several pieces of text that did basically the same
> thing (give the LSR permission/requirements to edit).
>
>
>

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 10 Jul 2008 10:11:34 -0700

(laughing) So you approve of Peter’s approval of your approval of my text. Cool.

:-)

Addison Phillips

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Davis
Sent: Thursday, July 10, 2008 10:00 AM
To: Peter Constable
Cc: Phillips, Addison; LTRU Working Group
Subject: Re: [Ltru] 3.1.4: description field uniqueness

+1

Mark
On Wed, Jul 9, 2008 at 9:47 PM, Peter Constable <[email-masked]<mailto:[email-masked]>> wrote:

+1

To: Phillips, Addison

Looks great.

Mark

of this document.</t>

</section>

Addison Phillips

It is an architecture.

Mark

Addison Phillips

It is an architecture.

Peter

Mark

Peter

Mark

(technical hat)

(editor hat)

Addison Phillips