Errors in Registry

"Doug Ewell" <[email protected]> Tue, 08 Jan 2019 16:57:41 -0700
Newsgroups gmane.ietf.languages
Message-ID <20190108165741.665a7a7059d7ee80bb4d670165c8327d.f9c23f4dc6.wbe@email03.godaddy.com>
I've done some experimenting recently with an XML version of the
Language Subtag Registry, which allowed me to build an XSD schema and
check the Registry much more robustly than would otherwise be possible
with the record-jar format.
 
In the process, I've discovered a few cases where the current Registry
is not compliant with the RFC 5646 definition. We need to examine these
cases and decide what to do about them.
 
The issues are as follows:
 
 
1. Extlangs 'lsg', 'rsi', 'yds' have no Preferred-Value
 
Section 2.2.2 says:
 
"3.  Extended language subtag records MUST include a 'Preferred-Value'. 
The 'Preferred-Value' and 'Subtag' fields MUST be identical."
 
Section 3.1.7 goes on to say:
 
"Changes to one subtag can affect other subtags as well: when proposing
changes to the registry, the Language Subtag Reviewer MUST review the
registry for such effects and propose the necessary changes using the
process in Section 3.5, although anyone MAY request such changes.  For
example: Suppose that subtag 'XX' has a 'Preferred-Value' of 'YY'.  If
'YY' later changes to have a 'Preferred-Value' of 'ZZ', then the
'Preferred-Value' for 'XX' MUST also change to be 'ZZ'."
 
This was clearly written with the use case in mind of a subtag whose
Preferred-Value changes from something to something else. The intent was
to prevent "chaining" of Preferred-Values, such that 'xxx' has a P-V of
'yyy', which has a P-V of 'zzz', and so forth.
 
However, a subtag can be deprecated with no Preferred-Value. This occurs
frequently when ISO 639-3 withdraws a language code element and the
decision doesn't provide a single replacement element.
 
In BCP 47, subtags for individual languages that are encompassed by an
ISO 639-3 macrolanguage have corresponding extlang subtags, with a
Preferred-Value of the language subtag (per 2.2.2). An important
extension to this scenario is that sign languages are considered to be
encompassed by [sgn], and also get extlangs.
 
Three sign languages have been withdrawn by ISO 639-3, all as
"nonexistent": [lsg] for Lyons Sign Language, [rsi] for Rennellese Sign
Language, and [yds] for Yiddish Sign Language. In an attempt to follow
Section 3.1.7, we removed the Preferred-Value from the extlang records
for 'lsg', 'rsi', and 'yds'. But this breaks the requirement in 2.2.2
that all extlangs must have a P-V which matches the subtag value.
 
Proposed action: Restore the P-V for these three deprecated extlang
subtags. They will point to deprecated language subtags, which is the
"chaining" we were trying to prevent, but that is less of a problem IMHO
than the violation of 2.2.2.
 
 
2. Variants 'arevela' and 'arevmda' have language subtags as their P-V
 
Section 3.1.2 says:
 
"Preferred-Value's field-body contains a canonical mapping from this
record's value to a modern equivalent that is preferred in its place. 
Depending on the value of the 'Type' field, this value can take
different forms: [...] For fields of type 'script', 'region', or
'variant', 'Preferred-Value' contains the subtag of the same type that
is preferred for forming the language tag."
 
We deprecated variant subtags 'arevela' for Eastern Armenian and
'arevmda' for Western Armenian when ISO 639-3 added language code
element [hyw], because now subtag 'hy' could refer specifically to
Eastern Armenian and 'hyw' would refer to Western Armenian, making the
variants unnecessary. But this is a violation of 3.1.2: the P-V is not
of the same type as the subtag.
 
Proposed action: Remove the P-V for each of these variant subtags, and
add a Comments field along the lines of "Preferred tag is hy", analogous
to 'heploc'.
 
 
If there is general agreement to make these changes, I'll post forms. I
do feel it's important to bring the Registry in line with its
specification.
 
 
--
Doug Ewell | Thornton, CO, US | ewellic.org