Re: XForms 1.1 is a Proposed Recommendation (Call for Review)

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