Re: XForms Transitional

Dave Raggett schreef:
> Do you have any particular suggestions on hybrid features?

I don’t think I can really talk here in terms of specific features, but 
I think the gist of it is what I said at the bottom; Web Forms 2.0 
offers a quite comprehensive DOM solution, with various methods, events 
and properties, but the declarative part of the story is a little weak. 
For XForms Transitional, it is the other way around.

It would be interesting to see what happens if you take Web Forms 2.0 as 
a base (because it’s the bigger, more complicated spec), and integrate 
all XForms Transitional features in them. Seeing how relatively similar 
they are, this shouldn’t be too difficult. You would end up with a 
solution that has more scripting power, yet also a simple declarative 
means that everyone can use to relatively complex form validation 
patterns, without having to know Javascript. And it would provide a nice 
starting point to start commenting and fine-tuning the integration.

> I agree that XPath imposes fewer constraints on field names, and that 
> is one of the reasons why it was picked for XForms as an XML 
> applications language. The user base for HTML tends to be more 
> familiar with JavaScript and the expression syntax common across the 
> family of languages derived from C. We also have the experience from 
> VoiceXML which is closely analogous to HTML with menus and forms, and 
> which uses JavaScript extensively for the forms data model. For HTML 
> itself, the DOM1 object model exposes field names as JavaScript 
> properties, e.g. document.forms[0].total for a field named "total". I 
> haven't heard of any practical problems with name clashes, and it is 
> easy to pick field names accordingly since these are only used 
> internally and not exposed to end users.

In Backbase 4.0, for this exact reason it is impossible (or at least 
was, when I last was in the office, which is like 5 months ago :)) to 
declare (using XML) new methods with parameter names using reserved 
Javascript keywords. They are mapped to local variables, and then 
eval-ed (or rather, new Function()-ed, iirc) before executing the method 
body, and whenever you used e.g. ‘with’ or ‘for’ it crashes.

If you are mapping the name to local variables, you must have this 
problem too. The difference with document.forms[0].total is that it’s 
not a local variable but a property of an object, which has no 
restrictions in its names, worst case (say, there’s a dash in it) it can 
even be addressed as document.forms[0]['total-items']. Which I forgot to 
mention, btw, dashes and various other characters are also impossible in 
form names. And they can’t start with a number, too.

I think this poses a pretty harsh restriction on the possible values. 
Saying that you can easily pick field names that won’t cause problems 
isn’t entirely true; authors may have an existing backend that they do 
not want to modify (or may even be a black box), and just upgrade the 
frontend. What’s more, as it would be going into the HTML 
implementation, it may break backwards compatibility.

Basically, putting this in the spec would require you to add a 
restriction to the possible values for an input name like name ∉ 
{‘block’, ‘break’, ‘const’, ‘continue’, ‘do’, ‘while’, ‘export’, ‘for’, 
‘in’, ‘each’, ‘function’, ‘if’, ‘else’, ‘import’, ‘label’, ‘return’, 
‘switch’, ‘throw’, ‘try’, ‘catch’, ‘var’, ‘while’, ‘with’, /^[^a-zA-Z]/, 
/[+\-*/%=><&|^~!?:,.]/} (and this list is just from the top of my head).

So I don’t think doing it this way is possible. Either the variables 
need to be passed on an object instead of directly as local variables, 
or it needs to be done otherwise. Actually, XPath will probably have 
similar problems. Either defining the variables on a JavaScript object 
(vars.x > vars.y) or providing an accessor method ($('x')—I am half 
kidding) will be necessary.

>> I also don’t like too much fuzzy logic for different date input 
>> formats, especially if you start considering that month notations 
>> like ‘jan’ and ‘mar’ are very locale-specific (‘mar’ is ‘maa’ in 
>> Dutch), it can get very complex; I would suggest restricting the 
>> allowed values for manual input to yyyy-mm-dd, and only one 
>> locale-specific notation (thus, not try to parse every possible 
>> form). It would also be nice if this were dependant on my locale and 
>> not the web site’s language/location.
>
> This is perhaps more up to what end users want and less about us as 
> web site developers. Meeting customer needs is very much a competitive 
> issue. If the browser limited the input format in the way you describe 
> web developers would rapidly find ways around that, e.g. by adapting 
> text controls in place of the built in date control. I suggest that we 
> should draw upon experience with spreadsheets, which are forgiving in 
> the wide variety of date formats they accept, but which reformat the 
> date to show what was understood by the system. Using the computer's 
> setting for locale seems very reasonable, but even there I can imagine 
> that for multilingual users, they might find it confusing if web page 
> was all in English, but the dates had to be entered in Dutch.

That sounds like a good idea, I suppose.

However, even now I am already having trouble when I need to enter a 
date format (“soo… in which format would they want me to input the date 
this time… day-month-year? month-day-year? I *think* this site is 
US-based, so it would probably be safe to go for the latter…”), so 
please keep it in mind. A lot of things are specific to the US and 
relatively alien to foreigners, and people don’t realise it when they’re 
creating a yet another web application that has the date input as 
mm/dd/yyyy.

Another example, I once entered a bid on eBay that had two zeroes too 
many, because I used a ‘,’ to delimit the decimals, and I happened to 
have opened eBay.com instead of eBay.nl which I normally use.

It’s a difficult problem, but if it could be fixed to provide a better 
user experience and leave less room for user errors, that would be 
great. In the eBay case, it would have helped if eBay had formatted the 
value I entered before submitting it, for example. It would have been 
even better if it had just accepted my input; that’s one of the problems 
with current web pages compared to desktop applications, they live in 
their own world and don’t care about UI consistency or user locale >.<.

> I agree and wonder what other data types would prove sufficiently 
> valuable to standardize on. One consideration is whether the input 
> could be described by a regular expression, in which case you could 
> use a text control. For email addresses, there is the consideration of 
> being able to offer users the means to pick addresses from their 
> address book. For web mail applications, users would expect to be able 
> to enter a list of addresses, in the same formats as they are used to. 
> This suggests that there is a need for control over whether one or 
> more addresses is permitted, and for the control to accept a range of 
> address formats, and to reformat them as appropriate, in a manner 
> analogous to date controls.

Well, with Javascript, if you needed more than one email address you 
could use the email address picker to let the user pick out each address 
individually and when it’s selected add it to another wider text field 
containing the complete list. Without, you could just duplicate the 
field a couple of times (or rather, use the declarative ‘repeat’ 
functionality), there’s a few webmail applications that do that, and in 
Thunderbird it actually also kind of works like that. So I think there 
are a number of solutions to that problem already.

By the way, with regard to email addresses and regular expressions, any 
check that is more than simply .*@.* takes the risk of being too 
limiting. E.g. consider people who have a . or a + in their email 
address (mine can have a +, to create aliases), or whose email address 
doesn’t have a tld but instead points to an intranet server. 
Implementing the real email-address grammar is a daunting task. 
Implementing the IRI grammar is even worse. At least, with regular 
expressions in Javascript it is :).

> Yes, you could just have editable="editable" or editable="true"

That seems better, yes.

>> Final thoughts…
>>
>> Web Forms 2.0 focuses a lot on the DOM, too much in my opinion (being 
>> used to the more declarative approach in Backbase), and the proposed 
>> attributes in XForms Transitional seem very nice and simple to use. 
>> However, XForms Transitional puts too little focus on the DOM. Both 
>> should provide means to do the same thing, where the DOM is suitable 
>> if you want to do more ‘power’-things the declarative means can’t 
>> handle.
>
> This is where it will be interesting to look at a synthesis of ideas, 
> and to study the opportunities emerging from a variety of use cases in 
> more detail, e.g. fully customizable presentation of error reports. 
> Experience with Web Forms 2.0 on Opera shows some of the problem that 
> can arise if full customization is not allowed: For instance the red 
> box that appears when you try to submit the form, where the box shows 
> the browser defined text "This value is not allowed by a script on 
> this page" and then followed by the text passed with the 
> setCustomValidity function. The application developer will want much 
> greater control than that, and will resort to workarounds if the 
> browser's new mechanisms aren't considered fit for the task.

Yes, and from real customer cases at Backbase.com, I know that customers 
have requested, and gone into production, with some pretty strange and 
complex requirements. I mentioned one earlier in a mail to public-html; 
the customer wanted error messages shown in the content, but in two 
locations, directly below the input, and in a summary at the bottom. 
What’s more, they wanted the input messages to show up immediately, but 
the summary only when the submit button was pressed.

Now that last thing they wanted may be a little too much, but if a 
simple yet powerful declarative means for error messages would be 
created (think <message for="input_zip" error="pattern">Your zip code 
needs to match the following patteren: 1234AB</message>), instead of 
depending on red background and popup balloons, that would be very 
interesting for a lot of application developers, and also designers.

>> Also, I wonder how this is actually related to XForms
>
> XForms Transitional is an incremental extension of the HTML4 markup 
> and object model that enables developers to take advantage of the 
> declarative power of XForms bind constraints whilst remaining within 
> the framework of HTML4 and text/html. Developers can gain some of
> the benefits of XForms without first having to learn about XML
> namespaces, XPath and a whole new way of doing forms. XForms offers 
> enterprise strength forms, and XForms Transitional provides a stepping 
> stone to realizing that potential for when people are ready to make 
> the transition to the power and flexibility of XML.

Oh right, I see that was in the spec :).


~Grauw

-- 
Ushiko-san! Kimi wa doushite, Ushiko-san nan da!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.