Re: forms-lite and data models

Hi Dave,

Yes, the XForms urlencoded submission methods for get and post do also 
create essentially the same flat structure, so it is clearly still 
possible to flatten the data down to what today's HTML browsers support.

However, today's browsers do also support the ability to create data that 
is not flat. You can still have a flattened view of it.  Implementations 
could provide both, and in fact it is easy to provide a flat version by 
in-order traversal of the hierarchic version.

As to using fieldset versus group, yes of course that would also be 
possible, and I think my prior post involving the purchase order used your 
fieldset as its basis and then showed what the canonical XForm looked like 
so that it was clear that the "name-as-data" proposal could actually scale 
up to solving a repetition problem.

My response to Mark (and Francisco) was not about whether a flat data 
model should be available, but rather what is the deeper underlying 
meaning that we want to define for interpreting existing HForms markup in 
the XForms architecture. 

In fact, I would go so far as to say that "name-as-data" provides the 
easiest way to define the flattened name space version that you want 
available.  By comparison, it is quite a bit more difficult to obtain the 
flat data model while describing Forms Tiny in terms of identified binds 
and XPath variables.  Our goal is to define Forms Tiny in terms of today's 
XForms architecture.  "name-as-data" benefits from adding the ability to 
say @mipcontext=".." on a bind. It's simple, harmless and really needed 
anyway.  By comparison, "identified bind and XPath variables" requires the 
addition of features that, to add fully to XForms, requires a substantial 
overhaul of the processing model.  And all for the purpose of trying 
really hard *not* to end up with the option of an hierarchic XML data 
model.

Cheers,
John M. Boyer, Ph.D.
STSM: Workplace Forms Architect and Researcher
Co-Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





Dave Raggett <dsr@w3.org> 
10/26/2006 11:08 AM

To
John Boyer/CanWest/IBM@IBMCA
cc
mark.birbeck@x-port.net, Francisco Monteiro <monterro2004@tiscali.co.uk>, 
www-forms@w3.org
Subject
Re: forms-lite and data models






On Thu, 26 Oct 2006, John Boyer wrote:

> 3) A third problem with the variable approach is that it breaks at 
> the first sight of a grouping. Suppose for example that you create 
> an "address block"
>
> <group name="address">
>  <label>Ship to:</label>
>  <input name="name" ...
>  <input name="street" ...
>  <input name="city" ...
>  <input name="region" ...
>  <input name="country" ...
>  <input name="postalcode" ...
> </group>
>
> Nice. Now you want it again because you need a "Bill to" address:
>
> <group name="billto">
>  <label>Bill to:</label>
>  <input name="name" ...
>  <input name="street" ...
>  <input name="city" ...
>  <input name="region" ...
>  <input name="country" ...
>  <input name="postalcode" ...
> </group>

For currently deployed web browsers the above means that form.street 
etc. is an array of two items. This is because the existing HTML 
forms object model uses a flat namespace for the fields belonging to 
a given form. If you know the missing structure, you can restore it 
from the data submitted to the server. The alternative is to use 
different names, e.g. with a prefix that distinguishes the fields 
from the shipping and billing addresses. This then requires a model 
the describes the relationship between these names and the 
structured data model. Such a model can be a little verbose.

By the way, in the spirit of only making incremental changes to 
HTML, I would suggest the use of the existing HTML fieldset and
legend elements in place of group and label above. This had the
further advantage that existing browsers provide a nice rendering
and understand the relationship between a fieldset and its caption
(as given by the legend element).

The billing/shipping address example is interesting in that it 
doesn't really show the need for structured references. You can
still indicate which fields are required, and you can define
expressions as to whether the shipping address needs to be filled
out via an attribute on the fieldset element. The forms-lite testbed 
supports the relevant attribute on fieldset elements for that 
purpose.

  Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett