Inputmode Attribute and Harmonization of XHTML-MP and XHTML-Basic

Steven, Members of the HTML Committee,

As you may know OMA XHTML-Mobile Profile 1.2 includes the attribute "inputmode" on textarea and input fields. The attribute is "stolen" directly from Xforms (and hence XHTML 2.0). We need to include the "inputmode" attribute in our DTD for XHTML-MP 1.2, and have done so as follows:

.....
	<!ENTITY % input.attlist  "INCLUDE" >
	<![%input.attlist;[
	<!ENTITY % InputType.class
	     "( text | password | checkbox | radio | submit
	      | reset | file | hidden | image | button )"
	>
	<!-- attribute 'name' required for all but submit & reset
	-->
	<!ATTLIST %input.qname;
	      %Common.attrib;
	      type         %InputType.class;        'text'
	      name         CDATA                    #IMPLIED
	      value        CDATA                    #IMPLIED
	      checked      ( checked )              #IMPLIED
	      disabled     ( disabled )             #IMPLIED
	      readonly     ( readonly )             #IMPLIED
	      size         %Number.datatype;        #IMPLIED
	      maxlength    %Number.datatype;        #IMPLIED
	      src          %URI.datatype;           #IMPLIED
	      alt          %Text.datatype;          #IMPLIED
	      tabindex     %Number.datatype;        #IMPLIED
	      accesskey    %Character.datatype;     #IMPLIED
	      accept       %ContentTypes.datatype;  #IMPLIED
	      inputmode    CDATA                    #IMPLIED
	>
	<!-- end of input.attlist -->]]>
.....
Note that the attribute is CDATA which essentially is "unconstrained". In your schema for XHTML 2.0 you show the attribute as xsd:string, similarly unconstrained. Some questions arise:

1. Given that the intent is to ultimately converge (harmonize) XHTML-MP and XHTML[-basic?] 1.x between OMA and W3C, are you comfortable with this DTD declaration, since you will ultimately inherit it in XHTML 1.x (1.2?)? (This begs the general question of DTD->Schema conversion.)

2. While the schema and DTD definitions are unconstrained, the specification does enumerate a list of modifier tokens (lowerCase, upperCase, titleCase, startUpper, digits, symbols, predictOn, predictOff, halfWidth	). Are we opening a door to a conformance problem by not enumerating these modifiers in the schema or DTD?

3. Case for the modifier tokens is apparently specified in Section E.3.2 [1], but no statement is made. What is the rule?

4. Examples and text lead the developer to believe that the attribute string is either a script name, a modifier token, or the combination of the two. In reality one can, and will have multiple modifier tokens such as " predictOn startUpper" or " latin predictOn lowerCase". Should there be any conformance statement relative to this, so that we guarantee consistent parsing of the attribute?

Thanks for taking a look at the issue.

                      -Bennett

[1]  XForms 1.0 (Second Edition) , W3C Recommendation 14 March 2006


NOKIA 
Bennett Marks  OMA-W3C Liaison
* 5 Wayside Rd., Burlington MA  01803 <http://maps.yahoo.com/maps_result?ed=E4X26.p_0TqPO2qgHsJUV0JQCx7aZzQ-&csz=Burlington+MA++01803&country=us&new=1&name=&qty=>       
* bennett.marks@nokia.com
* +1 781 308 6556 <tel:+17813086556>  [mobile]
* +1 781 993 1911 <tel:+17819931911%20call-type=fax>  [fax]        
Skype: bennettmarks  Yahoo:bennettmarks439