- From: Martin Duerst <duerst@it.aoyama.ac.jp>
- Date: Thu, 25 Oct 2007 15:43:53 +0900
- To: "Steven Pemberton" <steven.pemberton@cwi.nl>
- Cc: public-i18n-core@w3.org, www-forms-editor@w3.org
Hello Steven, At 00:45 07/10/25, Steven Pemberton wrote: > >Martin, > >I think then that I understand your answer to be: the list should be in >the spec. Yes indeed. >Since you produced the list in the original case, I wonder if you would be >so kind to refresh it for us, since there is no one currently in the WG >that has the expertise to do that. No problem. What exact form do you prefer? I can send you a HTML table based on the one currently at http://www.w3.org/TR/xforms11/#mode-scripts, with the additions (as listed below). If you are editing from some XML form, I'll try to handle that, too. Also, please tell me what kind of change markup you are using, if any. I have no problem doing the work, but I'd like somebody else (could be XForms WG or I18N Core WG) to crosscheck. Regards, Martin. >Best wishes, > >Steven > >On Sun, 17 Jun 2007 10:24:04 +0200, Martin Duerst <duerst@it.aoyama.ac.jp> >wrote: > >> >> Hello Steven, >> >> At 04:33 07/06/14, Steven Pemberton wrote: >>> Martin, >>> >>> I wonder if it woudn't be more efficient to have this list by reference >>> rather >>> than by inclusion. >>> >>> Since you are the author of this section, would you be willing to >>> suggest the >>> text to replace the list with references to the normative specs? >> >> This may make sense to some extent, but it's not totally clear that >> all future additions to the Unicode list of scripts can be just added >> to the list of input mode tags in XForms. It is certainly not the case >> that the current list of scripts in Unicode is identical with the >> (currently proposed, incl. below) list of tags in XForms. >> >> Also, because there are changes in spelling, I think it's much >> more useful for implementers and users to have a full list. >> What I could immagine is that we add a sentence saying something >> like "it is expected that future versions of this specification >> will include tokens for scripts added to Unicode wherever that >> makes sense". >> >> Regards, Martin. >> >>> Best wishes, >>> >>> Steven Pemberton >>> >>>> Appendix E of this specification (http://www.w3.org/TR/xforms11/#mode), >>>> entitled "Input Modes", should be updated to be in sync with the most >>>> recent list of scripts from Unicode/ISO 10646. >>>> >>>> A rough count (using the Unix 'wc' utilty) showed that about 15 >>>> scripts are missing from the list of tokens at >>>> http://www.w3.org/TR/xforms11/#mode-values. >>>> >>>> A point-by-point comparison with >>>> http://www.unicode.org/Public/5.0.0/ucd/PropertyValueAliases.txt >>>> (look below the line "# Script (sc)") gave the following list >>>> (more than 15 because E.3.1 contains quite a few special values): >>>> (starting with lowercase and converting spaces to camelcase in >>>> line with the currently available tokens (e.g. canaidianAboriginal)). >>>> >>>> balinese >>>> buginese >>>> coptic >>>> cypriot >>>> glagolitic >>>> kharoshthi >>>> limbu >>>> linearB >>>> nko >>>> osmanya >>>> phagsPa >>>> phoenician >>>> shavian >>>> sylotiNagri >>>> taiLe >>>> newTaiLue >>>> tifinagh >>>> ugaritic >>>> oldPersian >>>> cuneiform >>>> >>>> This list of tokens can be included as is (with "Unicode script name" >>>> in the Comments column), but should be cross-checked to make sure >>>> I didn't miss anything. The text above the table can then be updated >>>> to say "The version of the Unicode Standard that these script name >>>> are taken from is 5.0." instead of "The version of the Unicode Standard >>>> that these script names are taken from is 3.2.". >>>> >>>> Many of the scripts (e.g. Cunieform) are not necessarily what you >>>> would expect as your typical XForms input, but some of the tokens >>>> already available in XForms 1.0 also don't have a high probability >>>> of usage, and it's better to be complete than to leave something out >>>> that later may be needed. >>>> >>>> Some people may raise the concern that adding these script tokens >>>> will force the spec to go to Last Call again. While this would be >>>> true for any genuinely new feature being added after Last Call, >>>> it is difficult to see why a new Last Call would be needed just >>>> because the list of scripts is being completed. No XForms >>>> implementation >>>> is forced to support all of these values anyway, but not including >>>> a value that's currently not supported would create a weird >>>> chicken-and-egg problem. >>>> >>>> Regards, Martin. >>>> >>>> >>>> #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University >>>> #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp >>>> >>>> >> >> >> #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University >> #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp >> >> > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp
Received on Thursday, 25 October 2007 07:04:37 UTC