W3C home > Mailing lists > Public > www-forms-editor@w3.org > February 2002

Last call comments

From: Martin Duerst <duerst@w3.org>
Date: Sat, 23 Feb 2002 04:08:20 +0900
Message-Id: <>
To: www-forms-editor@w3.org
Cc: w3c-i18n-ig@w3.org
Dear XForms WG,

I found some more time to look through XForms.

Below are the most important comments. I have a lot of
small editorial comments, too, but I suggest that it's
more efficient if I sit together with some of you next
week in Cannes.

I have copied the I18N IG because many of my comments are
I18N-related; the I18N WG may want (or not) to endorse some
of these comments, although that will not be possible before
the end of the official last call period.
[I18N IG: Please note that the www-forms-editor@w3.org is
publicly archived.]

- IRI/anyURI: There should be a note that data of type anyURI,
   and xlink:href, are internationalized. Otherwise, it's easy
   for implementers to miss this. A wording like in XML Signature
   (sorry no pointer, currently offline) is a good start. It could
   go into 3.2 and/or 3.8. The spec should make clear that the
   conversion (->UTF-8->%HH) only happens when anyURIs get resolved,
   not in XForms or as part of an instance.

- Bidi: I remember Jonathan Rosenne once making a comment about
   a problem with bidirectionality and HTML forms. I think it
   was that the base direction of an input field, as used by the
   user, could not be transmitted to the server. This is also
   a problem for XForms. Even more, there is no way to set the
   base directionality for an input field. This looks like a
   step back from HTML. (Please note that the base directionality
   of a text is related to the semantics of that text, and not
   just a presentation issue.) [A generalization of this is
   complex types as single form controls, e.g. for HTML fragment
   input,... My personal opinion is that the WG should at least
   have an idea of how they plan to add that in a later version.]

- In 2.2, an example with a Date is given. The HTML example is not
   very good, because usually, there are separate fields for month
   and year of the expiration date. An XForms example of the
   presentation to the user is not given. If the user is
   supposed to type in 2002-03, this just won't work anywhere in
   the world. It is also not very clear how the gYearMonth type
   would get translated into a reasonable UI component (in particular
   because it may be localized, where e.g. in Japan, the year
   would come first, with the consequences that many people would
   interpret the first two digits as the year rather than the
   month. There are several more problems with dates. In particular,
   I think that in section 8.1, it is very important to say clearly
   that a simple text field is not a good idea for date input.

- Only allowing 'true' and 'false' for boolean values
   is more language-dependent than necessary. '0' and '1' should
   also be allowed, also to fit with XML Schema.

Regards,   Martin.
Received on Friday, 22 February 2002 14:11:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:38:05 UTC