Dear fellow JAC members, The "resolutions" from the JAC meeting in Washington are very good indeed. I have just a few comments. Most of them are minor clarifications. I have copied in the text of the resolutions document below. It may lose even more of its formatting going through various conversion processes, but you all have the original document to compare with. Please see below. The first comment is under item 184.108.40.206, so just skip down quite a bit. Best regards Håvard ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Håvard Hjulstad mailto:[log in to unmask] Rådet for teknisk terminologi (Norwegian Council for Technical Terminology) Postboks 41 Blindern NO-0313 Oslo, Norway (besøksadresse/visiting address: Forskningsveien 3 B) tel: +47-23198040 faks: +47-23198041 http://www.rtt.org/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > -----Original Message----- > From: Rebecca S. Guenther [SMTP:[log in to unmask]] > Sent: Tuesday, February 29, 2000 9:07 PM > To: [log in to unmask] > Subject: Resolutions > > Attached to this message is a file containing the resolutions from our ISO > 639 JAC meeting on 17-18 Feb. 2000. > > I do plan to edit documents N2 and N3 as well as all the work we agreed > upon on the Web site. I just haven't yet had time. > > Thank you all for your hard work. It is clear from this document how much > we accomplished! > > Rebecca > > > > ===== TEXT COPIED IN =====> > > > ISO 639/JAC Resolutions > February 17-February 18, 2000 > > 1. JAC N2: Rules of Procedure for Conducting Business > 1. Composition of the Joint Advisory Committee > 1. 3.2. Voting > 1. Because Mr. Vervoorn was not present and > because the group wanted to accomplish its goals, Ms. Guenther recommended > to take two votes where at least five positive votes would be required in > the second vote to pass a resolution. > 2. 3.3 Role of Observers > 1. It was agreed that each TC could appoint no > more than 3 observers each, making a total of six, not five observers. > 2. Observers / Technical Advisors are experts > on specific points. They should serve on an Ad Hoc basis based on the > needs of the community. > 3. Members can request additional consultants > to the Chair as technical experts. > 2. Procedures for conducting business by electronic > mail > 1. Electronic communications > 1. There will be two discussion lists > (1) The JAC list will include appointed members > and observers. > (2) [log in to unmask] is the general discussion > list. Directions about how to subscribe will be added to the webpage in > the future. (It does not use list software, but there is an address for > requests). > (3) The technical experts may wish to summarize > the discussion of the general list to the JAC list in some cases. > (4) Official JAC documents shall be distributed > to the general public only after consultation with the chair. > 2. Electronic voting procedures > 1. Voting will take place on the list. > 2. A paper-based record for this must be kept. > 3. Votes will be generally submitted within two > weeks of the e-distribution. However, any extensions of this > period/deadlines, when necessary, should be stated in the > request-for-a-vote document. > 4. If a JAC member does not vote after two > consecutive times, the JAC chair will inform the appropriate ISO > sub-committee (TC37/SC2 or TC46/SC4) and request a replacement. > 5. Members are replaced as necessary. > 3. Deadlines for response > 1. Two weeks for voting. > 1. 2. The RA should give the requester > notification of receipt no later than two weeks after the request has been > received. > 3. One month for the JAC deliberations allows > time for a second vote and additional information. > 4. The requester should be informed of the > result in six weeks to two months from the time the request is submitted > to the RA, if possible. > 5. ISO 639/JAC is consulted after the RA > determines that the request meets the relevant criteria. This should be > within four weeks of the request=s receipt. > 6. A flow chart that outlines the time frame > may be developed and placed on the website. Mr. Galinski agreed to work > on this. > 7. Results of JAC actions will be publicized. > > 2. JAC N3: Working Principles for ISO 639 Maintenance > 1. Terminology > 1. The two standards should attempt to use the > same terminology to help the users in regards to the terms, ACode,@ > ACodes,@ ACode Elements,@ and AIdentifiers.@ > 2. However, no consensus was agreed upon. A > decision will be made after the balloting of ISO 639-1/DIS. > 3. The document will be generalized to include > information about both parts of the standard. > 2. Definition of new language codes > 1. Procedures > 1. Some wording changes will be incorporated as > suggested in N13 by Mr. Everson. > 2. Criteria > 1. Number of documents. Documents include all > forms of material and thus, not only text. > 2. Collective codes. ISO 639-1 does not have > collective codes. When the need arises to code for a group of languages, > the Alpha-3 codes will be used. > 3. Scripts. The following should be added to > the statement on scripts: > (1) If a language uses more than one script or > orthography, it is not normally given a new symbol. > (2) The ISO standard script name should be: Code > for the representation of names of scripts. > 4. Dialects. The difference between dialects > and languages will be decided on a case to case situation. > 3. Choice of new language codes > 1. The first bullet point will be reworded > similar to that in 639-1 and the phrase ALatin-alphabet@ should further > specify which Latin letters are used. > 1. 2. The JAC will try to base the code on > the vernacular as much as possible. ARequests by the countries or country > or sponsor submitting the requestA is possible language for the editing of > this document. > 3. In regards to prefixes, the example of > Swahili and KiSwahili should be used in the documentation instead of the > Aotshiherero@ example. This will state that Athe prefix is not regarded > as part of the language name for purposes of assigning a code.@ > 4. Changes of existing language codes > 1. It was decided that codes shall not be > changed. This will be stated more firmly in the documentation. > 1. Second bullet should read: AIn the rare case > that a code is changed, the old code shall not be reassigned and the > request goes through the same process as new codes.@ > 2. Requesters will be directed to look at the > MARC Code List for Languages when they are in the need of variant names > for languages. Variant names may be included in the language name > separated by a semicolon in the future. No effort will be made by the > Standard to collect these. > 3. The standard will be amended to take out the > footnote concerning the possible change of the ISO 639-2/T code for > Spanish. > 5. Relationship between ISO 639-1 and ISO 639-2 > 1. ISO 639-1 shall remain a subset of ISO 639-2 > 1. No new 2 letter codes can be added without > also adding a corresponding 3-letter code. > 2. In the future, the two standards will be > presented as one. > 3. At a certain point in time (probably after > approval of the ISO 639-1 DIS), the alpha-2 code list will be frozen. > Then only alpha-3 codes will be added. [H.Hjulstad:] This needs to be modified! Any item that is already in 639-2 at the point of "freezing" 639-1, may not be added in 639-1. However, for items that are new to both parts, may be considered for inclusion in both parts, or in 639-2 only. New items that have been accepted in 639-2, may not AT A LATER DATE be accepted also in 639-1. The point in time of this "freezing" should NOT be at the approval of the DIS, but at the approval of the IS (in practise FDIS), since we don't know now how many DISes we might need and how many changes there will be. I am not quite certain that the whole issue of "freezing" 639-1 is finalized! > 4. If possible, new codes introduced into ISO > 639-1 will agree with those in ISO 639-2 if already defined (i.e. have two > letters in common). > > 3. JAC N10: Website > 1. There will be one central ISO 639 page with both the > ISO 639-1 and ISO 639-2 pages linked from it. > 1. The ISO 639-1 introductory page will be > modeled after the ISO 639-2 one. > 2. The same form for requesting changes will be > used (it will state whether the request is for ISO 639-1, ISO 639-2, or > both). > 3. The criteria for requesting changes for each > part will be available on the page. Mr. Galinski has prepared the ISO > 639-1 criteria. See N20 > 2. Form for registration of new codes > 1. A section will be added for additional names > in indigenous languages. (The choice of the word Aindigenous@ is used > instead of Aoriginal.@) [H.Hjulstad:] There is a misunderstanding (or bad wording) here. The phrase "additional names in indigenous languages" hardly makes sense. May be the following wording: "A section will be added to submit information on the indigenous name of the language". > 1. 2. A section for additional information > will be added on the form > 3. A section for code suggestions will be added > with a parenthetical note that there is no guarantee that a requester will > receive the suggested code. > 4. The title is: ISO 639 Registration Form > 3. The e-mail generated by the form is sent to the JAC > chair. > 1. If there is a two character code request, it > must be referred then to the appropriate ISO 639-1/RA chair. > A. ISO members need to request approval to have the > standard on its website; this has already been done for ISO 639-2. > 4. The AFunctions of the ISO authority@ link will state > the purpose found in the introduction of the standard. > 5. The ADevelopment@ link will contain historical > information about each standard and the JAC. > 6. Links will be made between the ISO secretariat > homepage and the ISO 639 page. > 7. There will be a AUseful Links@ page added to the > website > 8. For the dissemination of changes to the standard, > Mr. Everson will draft a web-based newsletter for review. > 9. When the chair rotates, LC will continue to host the > page. The current chair will maintain it and send files to the host as > appropriate. > 10. For security purposes, some documents will be > available, but not linked from the JAC page (or password protection will > be available). > > 4. JAC N4: Changes to be considered at JAC meeting. > 1. Voting occurred on each proposal. > 2. Principles previously agreed upon were followed. > 3. Votes > 1. Serbian: change scc to srb : Rejected > 2. Serbian: change scc to srp: Rejected > 3. Croatian: change scr to hrv: Rejected > 4. Croatian: change scr to cro/hrv: Rejected > 5. Serbo-Croatian: add scc and scr for > Serbo-Croatian (1892-1990): Rejected > 6. Discontinue sh in ISO 639-1 and never reuse: > Approved. [H.Hjulstad:] Yes, but I am not sure that "discontinued" is the best word. Should we say "deprecated"? Would we also regard the old symbols "iw" (= he), "in" (= id), and "ji" (= yi) as "deprecated" in more or less the same way, and threat them in a table note? > 1. A table note must be in the table at sh to > show the historical status of it. > 2. A hyphen before the code could indicate that > discontinued codes could be used. > 7. Bosnian: Approved with codes bos and bs. > 8. Low German: request for a two letter and a > three letter > (1) Need more research/further study > (1) Sufficient number of documents needs to be > indicated. > (1) (2) Is this a code for low Germanic > languages as a collective? > (3) Mr. Everson will forward these questions to > the Germans and then report back to the group for a e-mail vote. > 9. Japanese (T code) change based on > vernacular: Rejected. > 10. Chichewa: This is the same as Nyanja, which > is already in ISO 639-2 as nya. > 11. Norwegian Bokmål: Add nb and nob: > Approved. > 12. Norwegian Nynorsk: Add nn and nno: > Approved. > 13. Sami Languages/Northern Sami > 1. Alpha-3 codes: change the definition of smi > to Sami (other) and add sme for Northern Sami > 2. Alpha-2 codes: change se (already in ISO > 639-1) to be Northern Sami : Approved without the accent on Sami. > 14. Montagnais: Deferred for more research. > 15. Naskapi: Deferred for more research. [H.Hjulstad:] = Neskapi (both names should be included) > 16. Balki: Ms. Guenther will contact the > requesting body (Iran) and request more information > 17. Parti: Ms. Guenther will contact the > requesting body (Iran) and request more information > 18. Kharazmi: Ms. Guenther will contact the > requesting body (Iran) and request more information > 19. Manchu: Add mnc: Approved. No alpha-2 code > is approved unless requested. [H.Hjulstad:] In my notes: approved 639-2; rejected 639-1 (not "deferred", as I guess must be the meaning of the text here. > 20. Sandawe: For stability of the codes, the > code for Sandawe will remain as is. > 21. Sign Languages > 1. Add sgn: Approved. > 2. Further thought will be given on development > of guidelines or links to other resources on the World Wide Web. > 22. Alsatian: Deferred for more research. Mr. > Galinski will further investigate Alsatian=s properties and similarities > to other languages/dialects, and Mr. Everson will ask some of the Germanic > listservs about it. > 23. Aromanian: Deferred. Further evidence of > the documents is needed. These will be circulated through the e-mail > lists. > 4. Ancient languages: The policy of the standard > stands. Any problem situations, etc. will be decided on a case-by-case > basis > 5. Conflicting codes between the two standards > 1. Cornish: Already published and thus, will > not be changed in either standard. > 2. Herero: Not published or approved and thus, > action will be taken by the ISO 639-1 editor to propose other codes. [H.Hjulstad:] The identifier hz has been proposed. > 1. 3. Kuanyama/Kwanyama: Not published or > approved and thus, action will be taken by the ISO 639-1 editor to propose > other codes. [H.Hjulstad:] The identifier kj has been proposed. > 4. Kdonga: Not published or approved and thus, > action will be taken by the ISO 639-1 editor to propose other codes. [H.Hjulstad:] Error in the name. Correct: Ndonga. The identifier ng has been proposed. > 5. Ndebele: In ISO 639-1, the code ND will > correspond with North and the editor of ISO 639-1 will propose a new code > for the South. [H.Hjulstad:] The identifier nr has been proposed for South Ndebele. > 6. An electronic distribution list should be set up to > publicize code changes, deletions, etc. > > V. JAC N5: An Aannotated version@ of Annex C of ISO/DIS 639-1 > A. The term ADefer@ means consider the request after it has been > formally requested. Those introduced into ISO 639-1 are already in ISO > 639-2, unless otherwise indicated. > * Abaza: defer > * Adyge: defer > * Aragonese: defer > * Aromanian; Arumanian: defer > * Arvanite: defer > * Asturian: defer > * Avestan: Accept into ISO 639-1; the code is being reconsidered [H.Hjulstad:] The identifier ae has been proposed. > * Balkar: defer > * Bosnian: Accept into ISO 639-1; the code: Abs@/ Abos@ for ISO 639-2 > * Chamorro: Accept into ISO 639-1; the code: Ach@ > * Chechen: Accept into ISO 639-1; the code: Ace@ > * Cherokee: defer > * Chichewa;Chewa: Accept into ISO 639-1; the code: ny. Already > accepted into ISO 639-2 as Nyanga (nya). [H.Hjulstad:] Error in the name. Correct: Nyanja. This item was already in both parts (as ny and nya respectively). The English name of the item with identifier ny/nya should be: Chichewa; Chewa; Nyanja. > * Church Slavonic; Church Slavic; Old Slavonic; Old Church Slavonic: > Accept into ISO 639-1; the code: Acu@ > * Chuvash: Accept into ISO 639-1; the code: Acv@ > * Dargwa: defer > * East Frisian; Frisian, East; Sater Frisian; Frisian, Sater: reject > * Efik: reject [H.Hjulstad:] Rejected in 639-1; is already accepted in 639-2 as efi (this should be made clear in the report, to avoid confusion. > * Erzya Mordvin: defer > * Franco-Provençal: defer > * Friulian: reject [H.Hjulstad:] Rejected in 639-1; is already accepted in 639-2 as fur > * Frisian, North; North Frisian: reject > * Gagauz: defer > * German, Low; Low German: defer (Already discussed for ISO 639-2) > * Gikuyu; Kikuyu: Accept into ISO 639-1; the code: Aki@ > * Hiri Motu: Accept into ISO 639-1; the code: Aho@ [H.Hjulstad:] Something like the following should be added: The name should be Hiri Motu only, not Motu. > * Inari Sami; Sami, Inari: defer > * Ingush: defer > * Istro-Romanian: reject > * Kabardian: defer > * Kalmyk: defer > * Karachay : defer (same as Balkar) > * Karaim: defer > * Karelian, North; North Karelian: defer > * Kashubian: defer for ISO 639-2 / Reject for ISO 639-1 > * Kikuyu; Gikuyu: Accept into ISO 639-1; the code: Aki@ > * Kildin Sami; Sami, Kildin: defer > * Komi: Accept into ISO 639-1; the code: Akv@ > * Kumyk: defer > * Ladin: reject > * Ladino: reject [H.Hjulstad:] Rejected in 639-1; is already accepted in 639-2 as lad > * Lak: defer > * Lallans; Lowlands Scots: reject [H.Hjulstad:] Rejected in 639-1; is already accepted in 639-2 as sco, English name "Scots" > * Lezghian: defer > * Livonian: defer for ISO 639-2 / Reject for ISO 639-1 > * Lower Sorbian; Sorbian, Lower: reject > * Lule Sami; Sami, Lule: defer > * Mandingo: reject [H.Hjulstad:] Rejected in 639-1; is already accepted in 639-2 as man > * Mari, Meadow; Meadow Mari; Mountain Mari: defer > * Marshall; Marshallese: Accept into ISO 639-1; the code: Amh@ > * Middle Persian; Persian, Middle: defer > * Mingrelian: reject > * Moksha Mordvin: defer > * Nama: defer > * Navajo; Navaho: Accept into ISO 639-1; the code: Anv@ > * Nenets: defer > * Nogai; Noghay: defer > * Northern Sami; Sami, Northern: Accept into ISO 639-1; the code: > Ase@ > * Norwegian Bokmål: Accept into ISO 639-1; the code: Anb@ / Accept > into ISO 639-2; the code: Anob@ > * Norwegian Nynorsk: Accept into ISO 639-1; the code: Ann@ / Accept > into ISO 639-2; the code: Anno@ > * Nyanja; Chechewa: Accept into ISO 639-1; the code: Any@ [H.Hjulstad:] It is "Chichewa". Cf comment to "Chichewa; Chewa; Nyanja" above. > * Old Persian; Persian, Old: reject > * Ossetian: Accept into ISO 639-1; the code: Aos@ > * Pali: Accept into ISO 639-1; the code: Api@ > * Provençal: Same as Occitan (post 1500); already in ISO 639-1 as Aoc@ > * Romany; Romani: reject [H.Hjulstad:] Rejected in 639-1; is already accepted in 639-2 as rom > * Ruthenian; Rusyn: defer for ISO 639-2 / reject for ISO 639-1 [H.Hjulstad:] My notes differ from this. In my notes it is "deferred" for both parts of the standard. It may not make that much difference, but it should be clarified. New vote? > * Sardinian: Accept into ISO 639-1; the code: Asc@ > * Skolt Sami; Sami, Skolt: defer > * Southern Sami; Sami, Southern: defer > * Tabasaran: defer > * Tahitian: Accept into ISO 639-1; the code: Aty@ > * Udmurt: defer > * Upper Sorbian, Sorbian, Upper: reject > * Valencian: defer > * Veps: reject > * Walloon: defer > * Yi: defer > > B. Norway, Finland, and Sweden will consult on Sami > languages > > 5. JAC N20: Criteria for ISO 639-1 > 1. This information will be published on the webpage. > 2. The criteria will be tested on a case-by-case basis. > 3. The criteria will emphasize the need for sufficient > number of existing terminologies in various subject fields. > 4. The code chosen will be as mnemonically similar to > the alpha-3 code as possible and ISO 639-1 will remain a subset. > > 6. Other Business > 1. Mr. Everson and Mr. Galinski will develop a > flowchart to illustrate the procedural time line of the code process that > will be on the webpage. > 2. More forms to facilitate the process for requesting > codes should be made available on the website: > 1. Registration (revised) > 2. Information that goes back to the requester > explaining the time frame for requests and procedures followed by both the > RA and JAC to determine codes. > 3. Voting forms. Negative votes must be > explained with ISO justification or comment. > 4. Final decision of JAC to go back to the > requester. > 5. Mechanism for disseminating results (i.e. > the newsletter). > 6. The forms above will be used both for ISO > 639-1 and ISO 639-2 > 3. Name of JAC: AISO 639/JAC@ (This has also been > referred to as ISO 639/RA JAC). > 4. Adoption of resolutions will be disseminated through > the e-mail list > 5. Next Meeting: This will be just after the chair > rotates in the beginning of 2002 or when the ISO 639-2 is up for review in > 2003. It will be decided during an electronic discussion in the future. > 6. Renewal of ISO 639-2 in 2003: a joint working group > may be needed. This may be the time to combine ISO 639-1 and ISO 639-2 > into one published standard. > > 7. Miscellaneous > 1. The Joint Working Group for ISO 639 1988 > 1. 1. There still exists a registration > authority for this, but activities are given to the JAC for now. > 2. Resolution: the JAC will replace the working > group when ISO 639-1 is published. Approval may be needed from TC37 and > TC46. [H.Hjulstad:] Is there something wrong here? What is "Joint Working Group for ISO 639 1988"??? ISO/TC37/SC2/WG1 is not a JWG as far as I know, and it produced ISO/DIS 639-1. However, the issue may be that there "in theory" still exists a Advisory Committee to 639:1988.