"Phillips, Addison" <addison at amazon dot com> wrote:
I removed the overall uniqueness requirement, narrowing it to within a record and focusing on formatting variations....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.
I read this as going beyond the existing ban on comma-inverted variations, and implying that other types of minor formatting variations should also be collapsed into one Description field. This would be VERY GOOD in my opinion. It would mean that hyphenated versus non-hyphenated variations ("Macedo Romanian") would be collapsed, as would variations that differ only in the type of apostrophe used. Is that correct?
If so, then we have to decide *which* variations to put in the Registry and which to leave out:
(language) Description: Macedo Romanian Description: Macedo-Romanian (scripts) Description: Geʻez Description: Ge'ez Description: Hangul Description: Hangŭl Description: Hanunoo Description: HanunóoI might actually argue in favor of keeping the accented and unaccented forms of Hangul and Hanunoo; at least they are meant to be visually different. The first two examples are a matter of individual taste in formatting; I would be surprised if any was expected to have normative staying power.
How about pairs of descriptions like the following, which exist because 639-3 has to distinguish between similarly named items where 639-2 (with its smaller repertoire) does not, and which we've kept because of the desire for perfect traceability:
Description: Swahili (macrolanguage) Description: Swahili Description: Ainu (Japan) Description: Ainu There are lots of these.This is a matter for LTRU, not ietf-languages, because we are the ones putting together draft-4645bis. It would, however, fall to ietf-languages to make similar decisions during the maintenance phase.
-- 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 Ltru at ietf.org https://www.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.