Feedback from the i18n WG on XForms 1.0

The W3C i18n WG reviewd the XForms 1.0 Last Call draft at its latest FTF 
meeting (minutes at 
http://www.w3.org/International/Group/2002/01/ftf16/minutes#review-xforms, 
W3C member-only) and at its latest telcon (minutes not yet available) 
and wishes to provide the following feedback.

1) On the application/x-www-form-urlencoded submission method

This form submission method has no means of providing required charset 
information to the receiver. As a result, it is very harmful to i18n 
concerns and has plagued the Web for too long.

The i18n WG requests, in order of preference:

  a) Remove 4.4.2 entirely (strongly preferred)
  b) Move 4.4.2 to an appendix
  c) Move 4.4.2 after the other 2 serialization methods

If 4.4.2 is not removed, make the note about this method being 
deprecated be normative (not a note) and move it to the start of the 
section.

If 4.4.2 is not removed, then "issue-utf8-encoding" should be resolved 
by mandating UTF-8 as the only permissible character encoding.


2) On the multipart/form-data submission method

This method does have a way of conveying charset information, but the 
XForms draft is silent about it.

The i18n WG requests that the mechanism for indicating character 
encoding (Content-Type header on each part with charset parameter) be 
mandated and shown in the examples.

Furthermore, this method suffers from the problem that the 'name' MIME 
parameter, used here to contain XPath expressions and therefore XML 
names, can only contain ASCII characters unless the value is encoded by 
the (fairly complex and error-prone) method of RFC 2049.

The i18n WG requests that this limitation be spelled out, that the 
capability to use the RFC 2049 method be mandated for both XForms 
producers and consumers using multipart/form-data submission and that 
the example in this section show at least one such 2049-encoded name 
parameter.


3) On the text/xml submission method

Note: there is a mistake in the first step, which specifies "XPath 
[XSLT]".  Choose one!

Although this submission method is very good, the choice of "text/xml" 
as the media type is unwise, because the default character encoding for 
this type is specified (RFC 3023) to be US-ASCII, irrespective of any 
encoding declaration in the entity itself. RFC 3023 says:

"Conformant with [RFC2046], if a text/xml entity is received with the 
charset parameter omitted, MIME processors and XML processors MUST use 
the default charset value of "us-ascii"[ASCII]."

The i18n WG requests that the media type be application/xml or perhaps a 
new type such as application/xforms+xml, instead of text/xml. A less 
preferred alternative would be to stay with text/xml but mandate the use 
of the charset parameter in the HTTP header of the POST submission.

Note that despite long-standing obligations from the relevant specs, 
HTTP transactions have always very poorly indicated charset, if at all.


4) General

Please make examples better internationalized (for instance change 
"First name" to "Given name").

Please include an example showing that the same model can be used with 
different user interfaces in different languages (fields laid out in 
different order, fields that appear in a certain language version of the 
form but not in some other, e.g. "state/province", labels in different 
language than content).


Regards,

-- 
François Yergeau
for the i18n WG

Received on Tuesday, 12 February 2002 18:09:02 UTC