W3C home > Mailing lists > Public > public-forms@w3.org > August 2009

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

From: Steven Pemberton <Steven.Pemberton@cwi.nl>
Date: Thu, 20 Aug 2009 16:22:41 +0200
To: "Forms WG" <public-forms@w3.org>
Message-ID: <op.uyysvhiwsmjzpq@steven-750g>
Forwarded without comment.

Steven

------- Forwarded message -------
From: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
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>
Cc:
Subject: Re: XForms 1.1 is a Proposed Recommendation (Call for Review)
Date: Thu, 20 Aug 2009 13:10:27 +0200

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
>
>
>
Received on Thursday, 20 August 2009 14:23:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:52 UTC