Thank you very much for your comments. I ask that any last minute comments be submitted to the listserv before COB today so that we can draw the discussion to a close. JAC Secretary, Melinda Lyons, is drafting a ballot which she will post to the JAC voting list later today or tomorrow.
If the answer is not in the first paragraph you have lost me... too busy for all this unnecessary longwinded stuff.
Maybe banging your head does not allow you to carefully read my messages.
Le 14 avr. 2014 à 10:24, Debbie Garside a écrit :
As I said, people get fed up with banging their heads against a brick wall. We have better things to do...
Please answer just one question, the code for Shikomor, is the request purely to facilitate your Administrative Language list?
1:As far as I can recall (but I may be wrong), BSI gave a plain YES vote without any comment when ISO 3166-1:2006, that introduced the administrative languages in ISO 3166, and this was after the letter from the ISO 639/RA-JAC against this introduction (and the WG 2 answer to this letter) had been distributed to all ISO/TC 46 member bodies.
2: It is a fact that, after ISO 3166-1:2006 had been adopted, you represented the BSI to an ISO/TC 46/WG 2 meeting in one occasion where you presented a New Work Item Project (NWIP) for a revision of the ISO 3166-1 standard including a deletion of administrative languages. You seem to think that everyone (but the awfull convenor at that time) of the TC 46/WG 2 was unanimously enthusiastic about your proposition and eager to eliminate the administrative languages from the ISO 3166 standard. This is not exactly how I remind this meeting.
3: Anyway, in the case that almost everybody had been as enthusiastic about your proposition as you seem to think, your NWIP would have been easily adopted. But we perfectly know that this has not been the case, in spite of the fact that we gave more time that was the rule to allow TC 46 member bodies to give a positive answer to the NWIP of the BSI.
4: After that, other people have been representing BSI in the WG 2 and seem not to share your view on these question, because they most willfully contribute to the maintenance of the considered columns (whose informative status is very clearly explicite) of the standard.
5: Moreover, as the next edition ISO 3166-1:2013 has been unanimously adopted by the 35 P-member bodies of the TC 46about this, I do not see the necessity to further discuss.
I will add that BIS, that is the national standardization body member of ISO for India, is one of the 33 O-member bodies of the ISO/TC 46 and, as such, received the drafts of ISO 3166-1:2006 and ISO 3166-1:2013 without giving a negative vote or a comment on these drafts as it would have been possible in case of disapprobation.
Le 10 avr. 2014 à 19:06, Debbie Garside a écrit :
You seem to have conveniently forgotten that TC46 WG2 agreed to remove the administrative languages list at a meeting that I attended as BSI representative in what would have been the next revision of the standard. It was minuted after I explained in depth as to why it was inappropriate for ISO 3166-1 to include administrative languages within the standard and unanimously agreed y TC46 WG2 to exclude the information in the next revision (with the exception of the Chair, Editor of the next version of the standard).
I am not going to go over all that again but it was agreed that a revision to the standard would be made. Unfortunately, it was never actioned as people do not have the time or inclination for depth arguments of the type we are seeing at this moment.
BTW, the corresponding columns in the standard were described as informative by one person... I was at that meeting too. This comment was based on this one person being presented with a list of administrative languages and with no reference made as to why TC37 disagreed with the representation.
Also, at that point in time the information contained within the administrative language section was totally incorrect in respect of both South African and Indian Administrative languages. No idea who is policing all this but I bet I could hazard a very good guess.
I gave up trying to right the wrongs made by TC46 WG2 in this respect because you can only bang your head against a brick wall for so long.
1: Concerning your point on coherence between codes in ISO 639-1, ISO 639-2 and ISO 639-3, I fully maintain my position. And let me add that this is not a personal approach, but that it is only the correct lecture of (notably) the text of clause 5 of ISO 639-4:2010. Moreover you give strictly no explanation why such a conception allows you to be of the opinion that "that is totally backwards and would lead to significant damage to the standard as well as significant problems for implanters and users". Anyway, this must be a personal (and recent ?) opinion, because no such opinion was expressed during the recent process preceding the edition of ISO 639-4 in 2010.
2: As far as I know, the ISO 639/RA-JAC expressed, in a paper that was distributed in the TC 46 before voting the revision of the ISO 639-1 standard that introduced the list of the administrative langages of each country, its opinion that this was not a good thing to do, specially because it was not possible to properly define the concept of an "official language" . This paper was considered with attention, and was very carefully answered. The answer was directed to the ISO 639/RA-JAC and received no more reaction. The final concept introduced in ISO 3166-1 was "administrative language", with a very precise and effective definition, the corresponding lists of administrative languages where established jointly with a work of the United Nations Group of Experts on Geographical Names, and the corresponding columns in the ISO 3166-1 standard where described as informative. These solutions were recognized as satisfying and the vote of the ISO/TC 46 was most positive for the adoption of the ISO 316-1:2006 standard. The three parts of the ISO 3166 standard have been revised in 2013, and the votes for part 1 (35 national standardization TC 46 voting members, 29 approbations and 6 abstentions) and 3 (35 national standardization TC 46 voting members, 28 approbations and 7 abstentions) were unanimous, the vote on part 2 (35 national standardization TC 46 voting members, 27 approbations, 7 abstentions and 1 reprobation) being quasi-unanimous, with only one negative vote. It was during the finalization of this process that ISO TC 46 unanimously, following an unanimous proposition of its WG 2, requested the ISO 639/RA-JAC to create alpha-2 ISO 639-1 code elements concerning some administrative languages. I do not think that such a process can be described as "an independant action of certain individuals", when this is only the application of decisions taken by about 35 national standardization ISO member bodies that are the P-members of the ISO/TC 46.
But, in fact, maybe that refusing to contribute to a positive answer of the ISO 639/RA-JAC to this request could be described as "an independant action of certain individuals".
Le 10 avr. 2014 à 17:16, Peter Constable a écrit :
But for something to be coded in 639-1, 639-2 or 639-3, it must be a distinct language. That is a sufficient condition for encoding in 639-3. Therefore, by simple deduction, to be encoded in 639-1 or 639-2, the concept must first be demonstrated that it qualifies for encoding in 639-3.
Your approach, Gerard, appears to be to say that something meets necessary conditions of 639-1, therefore qualifies for encoding in 639-1 (without any additional consideration of sufficient conditions), and subsequently there is an obligation for encoding in 639-2 and 639-3. IMO, that is totally backwards and would lead to significant damage to the standard as well as significant problems for implementers and users.
John, I will add to my earlier comments observations on this information in the request:
>> Evidence: All federal laws of Comoros
>> All local laws in each of the three federated islands Treaties with other countries
>> National Evidence: Government of Comoros
>> Size Evidence: national literature
>> Official Evidence: National language by article 1 of the Constitution
>> Education Evidence: In the three federated islands of Comoros
These are assertions without any ostensive evidence. In this case, based on other information I have seen, I think this evidence is suspect.
Also, there is no indication of any end users or implementers requesting this. All we know is that, having come from the TC46 liaison, it appears that TC46 thinks this is needed. Yet I haven’t heard any of the TC46 representatives hear speak up to explain why it’s needed, nor do I know that this is based on a consensus decision within TC 46 rather than an independent action on the part of certain individuals.
What I know from history is that a _different_ part of TC46 that maintains ISO 3166-1 has a table they maintain and that they like to fill it in with identifiers from 639. Yet this JAC, with representation from TC46, gave clear indication years ago that the table in 3166-1 in question was ill-advised. If the basis of this request is in relation to that table in 3166-1, then TC46 should not expect the JAC to support it.
So, I would find it helpful if our TC46 representatives could clarify the basis of this request coming from TC46, and what the intended usage would be.
In my opinion, there is no doubt that the correct interpretation of the current text of ISO 639 is the "blunt" one:
- every language name coded in ISO 639-1 must also be coded in ISO 639-2, and
- every individual language name coded in ISO 639-2 must also be coded in ISO 639-3.
This is most clearly made explicit in clause "5 Relations entre les parties de l'ISO 639", more specifically in subclause "5.3 Principes", of ISO 639-4 "General principles of coding of the representation of names of languages and related entities, and application guidelines".
Le 10 avr. 2014 à 09:32, Sebastian Drude a écrit :
I did not want to formulate it so bluntly, but I fully agree, although that passage could also be interpreted as “if something is accepted in part (1 and) 2, it is also automatically included in part 3” – but that is clearly not appropriate as part 3 has its own mechanism for inclusion of new code points.
I ask for your understanding if, in the interest of being quick and short, this mail may not fulfil all requirements on form and politeness.
PD Dr. Sebastian Drude, The Language Archive
Max-Planck-Institute for Psycholinguistics
P.O. Box 310, 6500 AH Nijmegen, The Netherlands