- From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
- Date: Thu, 20 Aug 2009 20:10:27 +0900
- To: Ian Jacobs <ij@w3.org>, "public-i18n-core@w3.org" <public-i18n-core@w3.org>, Steven Pemberton <steven@w3.org>, John Boyer <boyerj@ca.ibm.com>
Great to see that XForms 1.1 is moving forward. I just looked at Appendix E, inputmode (http://www.w3.org/TR/2009/PR-xforms11-20090818/#mode), and found the following problems that I think have to (and can) be fixed before going to REC. [Bcc to chairs to avoid further cross-posting (unless somebody thinks this is necessary).] 1) (IMPORTANT) Case of tokens: Since XForms 1.0, inputmode tokens are case-sensitive. (see first paragraph of E.1: "Tokens are case-sensitive."). XForms 1.0 (see http://www.w3.org/TR/xforms/#mode) lists all tokens explicitly starting with a lower-case letter. However, XForms 1.1 lists all these values starting with an upper-case letter. This is contradictory. Proposed fixes: a) In the second paragraph of E.3.1, Script Tokens, change the sentence: "The allowable values are those listed in the column "Property Value Alias" with the underscore character (_) removed, and excluding the two values "Common", and "Unknown"." to: "The allowable values are those listed in the column "Property Value Alias" with the underscore character (_) removed, the first letter changed to lower-case, and excluding the two values "Common", and "Unknown"." b) Change all the initial letters of the tokens in the list in E.3.1, Script Tokens, to lower-case. Please note that medial upper-case letters have to stay upper-case, e.g. 'CanadianAboriginal' has to be changed to 'canadianAboriginal', NOT 'canadianaboriginal'. c) (if possible) Change the tokens in the token list in E.3.1, Script Tokens, (and ideally in other cases such as examples, too) to <code>...</code> markup (in the html version) to clearly indicate that these are protocol/format values. 2) (major) The appendix describing inputmode is labeled as "non-normative" in XForms 1.1, in contrast to XForm 1.0, where it is not labeled and therefore normative. The appendix contains 'should' and 'may' normative language (no 'must'). A "non-normative" labeling gives a strong incentive for non-interoperability, which I think W3C should definitely avoid. No reason is given for why this Appendix is non-normative. (This is in contrast e.g. to Appendix G, XForms and Styling.) It is difficult to guess what the motivation for this change was, but it was probably one (or a combination) of the following: a) Intent to allow other values for the (normative!) 'inputmode' attribute than those given in the appendix. This is the message that the "non-normative" label sends to implementers. The result would be non-interoperability, which isn't the purpose of a W3C Recommendation. It is technically unnecessary (because the spec allows absolute URIs, which can be very short, as tokens). If specific cases are known, this may indicate a shortcoming in the specification itself, which should be fixed. b) Concern about lack of implementations. It is unreasonable for any specific implementation to support e.g. all tokens predefined in Appendix E; this is mentioned explicitly. There are other reasons, such as the conflict between high-end (where XForms is most suited) and low-end (e.g. small devices, where inputmode is most helpful) implementations and the target markets of some implementations, for why e.g. requiring two full implementations of all XForms 1.1 features (including inputmode). Nevertheless, the inputmethod attribute itself is a normative part of the XForms 1.1 spec (see Section 8.1, The XForms Core Form Controls Module), which makes it look very strange that its contents specification is non-normative. If there are some specific concerns regarding implementations, these should be addressed more specifically. c) Expectation for an independent specification. This is the reason given for why Appendix G, XForms and Styling, is labeled non-normative. For inputmode tokens, there is no intent nor reason to create a separate specification. (inputmode is also defined at http://www.w3.org/TR/xhtml-basic/#s_inputmode, fully normative.) [What is somewhat inexplanable to me is that this spec uses a word-by-word copy (copying of spec text by itself not necessarily the best practice) of the XForms 1.0 version of appendix E although the XHTML and the XForms efforts have been closely coordinated for a long time and the efforts to update the XForms spec to cover more scripts in sync with the addition of scripts to Unicode go back several years.] In conclusion, the label "non-normative" should be removed. If necessary, the conformance criteria and/or the criteria for exiting CR should be adapted. (Especially for the conformance criteria, I don't think there is such a need, because there are no 'must's in Appendix E.) Making something non-normative which (where used) is clearly counterproductive. 3) (minor) Section E.5, Examples, says: "it will be replaced by actual syntax in a later version of this specification." This may have been appropriate for XForms 1.0, but no longer for XForms 1.1. Please remove this sentence, replacing the preceding semicolon with a period. 4) (minor) E.3 List of Tokens: Improve alphabetical ordering: Some improvements have been made over XForms 1.0, but the following fixes would make the list completely alphabetical, which would probably be best. The following fixes are necessary: Move cunieform up. Move deseret up. Move han up. Move kannada up. Move katakana up. Move newTaiLue up. Move oldItalic down. Move oldPersian up. Move tagalog up. Move Tifinagh down. 5) (needs to be addressed separately) Applicability to XForms 1.0 and XHTML Basic 1.1: The updates to Appendix E by their very nature are backwards-compatible and should be, in whatever form deemed appropriate, applied to XForms 1.0 as soon as possible. Possibly the easiest way is to add a sentence such as "In addition, token values from XForms 1.1 may also be used." after the sentence "The version of the Unicode Standard that these script names are taken from is 3.2." to the respective sections on token values via the errata process. With kind regards, Martin. On 2009/08/19 3:59, Ian Jacobs wrote: > Dear Advisory Committee representative, > > W3C is pleased to announce the advancement of XForms 1.1 to Proposed > Recommendation: > http://www.w3.org/TR/2009/PR-xforms11-20090818/ > > The approval and publication are in response to this transition request: > http://lists.w3.org/Archives/Member/chairs/2009AprJun/0109 > > Please review the specification and indicate whether you endorse it as a > W3C Recommendation or object to its advancement by completing the > following questionnaire: > http://www.w3.org/2002/09/wbs/33280/xforms2009/ > > Additional details about the review are available in the questionnaire. > > This questionnaire is open for answers until 23:59, Boston time on > 2009-09-22. > > More information about the Forms Working Group is available on the group > home page: > http://www.w3.org/MarkUp/Forms/ > > If you should have any questions or need further information, please > contact Steven Pemberton <steven@w3.org>, Forms Working Group Team Contact. > > This Call for Review follows section 7.4.4 of the W3C Process Document: > http://www.w3.org/2005/10/Process-20051014/tr#cfr > > Thank you, > > For Tim Berners-Lee, W3C Director, > Philippe Le Hégaret, Interaction Domain Lead, and > Steven Pemberton, Forms Working Group Team Contact; > Ian Jacobs, Head of W3C Communications > > -- > Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ > Tel: +1 718 260 9447 > > > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp
Received on Thursday, 20 August 2009 11:11:33 UTC