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

Steven:
>> Would this satisfy you for now?

Martin:
> More or less, I guess.

Thank you for this Martin.

To answer your direct questions:

>> Thanks for this mail. However, it has put us in a difficult situation,
>> because these are more like last call comments, or at best CR. However,  
>> PR
>> is usually a yes/no situation, not a situation that allows changes  
>> without going back to last call or CR.
>
> I understand that there are differences in what works or not, or what's  
> easy or not, at each stage. I just hope we can make the best out of the  
> situation. In some cases, it's better to fix something late than never.  
> The SKOS case thus recently may serve as a good example.
>
>> So with a heavy heart we
>
> The WG? The Team? Who else?

The WG

>> have discussed your comments, and frankly fear
>> for the future of this feature in XForms. If we make any normative  
>> change
>> as you ask for, we fear we will be sent back to last call or CR.
>
> Usually, first to make some changes, and then to just see what that  
> implies is not the best way to address things. What you should do in  
> such a situation is to talk to people such as Philippe, Ian, and maybe  
> even Tim, to get an "expert opinion" before you make the actual change.

Well, we have dealt with enough PR transitions to know what can be changed  
at the last minute like this.

>> If we go
>> back to CR with this feature as normatively required, it will be  
>> seriously
>> at risk, since we won't be able to get the implementations in the short
>> term.
>
> I agree that it would be a bad idea to go back to CR, and it would be a  
> bad idea to lose inputmode.
>
>> We do want to make this feature normative in the long run, because we
>> think it is important, and we will do once implementors implement it. We
>> want it to be in the spec so that when implementors do implement it,  
>> they
>> use the method defined here.
>
> I very much agree with having inputmode well-defined and well  
> implemented, even if it takes some time.
>
> I still think there is some heavy confusion between  
> "normative"/"non-normative"(aka informative) and "mandatory to be  
> implemented"/"optional to implement" (defining conformance  
> requirements). I tried to explain this in quite some detail in my  
> original mail, but apparently, this wasn't understood. I suggest you go  
> back again and read it carefully. We may be stuck with the present  
> unappropriate "non-normative" label, but it would at least be good to  
> acknowledge that this label may be highly misleading and inappropriate.

The point is, we have made the attribute normative so that implementations  
understand it is there, do not reject it and so on.

Were have made the values non-normative for the time being to allow for  
implementation experience to build up. Of course, they are only hints  
anyway, so this doesn't cause too much trouble.

>> So here is our proposal: We replace 'case-sensitive' with
>> 'case-insensitive'. This was a mistake on our behalf that no-one
>> spotted, since it would make existing content non-conforming.
>
> Can you expand? XForms 1.0 says that inputmode tokens are  
> case-sensitive. What exactly has changed between XForms 1.0 and XForms  
> 1.1 to suddenly make them case-insensitive?

You agreed with us that the values would now come from another spec, and  
that spec says that the values are case-insensitive.

> You seem to imply that there is existing content that uses tokens that  
> start with an upper-case letter.

No, the other way round. There is existing content that starts with a  
lower-case letter.

> How do you know? How much is there, and why?

Not relevant. There is an existing spec, and we don't want to break *any*  
existing content.

> If it is indeed the case that there is such content, and there are  
> implementations that do comparison case-insensitively, then this might  
> be fine, but strictly speaking, it would create a discrepancy between  
> XForms 1.0 and 1.1.

It makes XForms 1.1 implementations accept more, and doesn't break any  
existing content.

> Also, please note that it is often easy to assume that comparisons are  
> case-insensitive, but that they are often in actual fact implemented  
> case-sensitively.

The spec we are referencing says that the values are case insensitive.

>> That we do not change non-normative to normative, but leave it as is.
>
> That may be unavoidable, but it would be great to acknowledge that you  
> understand what went wrong.

That your comments arrived too late you mean?

Best wishes,

Steven

>> That we change the other editorial erros.
>
> Of course, please go ahead and fix these.
>
>> Would this satisfy you for now?
>
> More or less, I guess.     Regards,   Martin.
>
>> Thanks!
>>
>> Best wishes,
>>
>> Steven
>>
>> On Thu, 20 Aug 2009 13:10:27 +0200, Martin J. Dürst
>> <duerst@it.aoyama.ac.jp> wrote:
>>
>>> 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 Friday, 11 September 2009 14:02:45 UTC