W3C home > Mailing lists > Public > public-html@w3.org > May 2007

Re: Architectural Consistency Requirements for Forms

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 3 May 2007 12:26:15 -0700
Message-Id: <0312923B-359D-4EBD-9766-82979B0059A1@apple.com>
Cc: public-html@w3.org
To: T.V Raman <raman@google.com>


On May 3, 2007, at 12:19 PM, T.V Raman wrote:

>
> Please re-read what I said carefully --- explicitly separated out
> the requirement from how XForms does it today.

In that case I am in total agreement. Apologies for the  
misunderstanding.

  - Maciej

>
>
>
> Maciej Stachowiak writes:
>>
>> On May 3, 2007, at 10:49 AM, T.V Raman wrote:
>>
>>>
>>> Here's one more that is not called out explicitly in 1..8:
>>>
>>> 9)  Given N controls that  are inter-dependent, enable "O(N)
>>>     wiring" rather than requiring "O(N^2) wiring".
>>
>> This seems like a fine requirement with a practical effect.
>>
>>> In the XForms world, this is met by having a data model to which
>>>     controls are wired. In the interest of consistency, and for
>>>     enabling the smooth on-ramp from HTML Forms that Mark Birbeck
>>>     has elucidated earlier, we should ensure that an author who
>>>     starts off writing a plain old HTML Form (i.e. no explicit
>>>     data model) can later add in a data model and additional
>>>     wiring without having to re-author the entire form.
>>
>> I think this part, though, is more questionable. Having an explicit
>> separate data model is one possible way of solving the problem, but
>> surely not the only way. Adding this constraint on allowable
>> solutions may overconstrain the problem, if we also want graceful
>> degradation in HTML4 UAs.
>>
>> Regards,
>> Maciej
>
> -- 
> Best Regards,
> --raman
>
> Title:  Research Scientist
> Email:  raman@google.com
> WWW:    http://emacspeak.sf.net/raman/
> Google: tv+raman
> GTalk:  raman@google.com, tv.raman.tv@gmail.com
> PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
>
Received on Thursday, 3 May 2007 19:26:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:15:58 GMT