Re: forms-lite and data models

Hi Mark and Francisco,

Well, first for Francisco, the use of id() does not work because the XPath 
data models we create
are for instance data, whereas the IDs on the binds are not in instance 
data.  So even with a 
<bind id="A" ... />, the function call id('A') would return empty nodeset.

Moreover, the idea has the same problems as Mark's variable idea, and the 
two have at least one
problem in common with the dot-dot problem.

1) We want authors to be able to type into expressions the names that they 
assigned.  We don't
want XForms processors to have to parse the XPath expressions, find all 
the node references
in the location paths and add  "../" or with "$" or id() or what have you 
to each. 

Mark argues that the form author would be asked to type the $.  The 
problem there is that the
first time they forget the $, it's just like forgetting "../".  It doesn't 
work and they don't know why. 

2) A second problem for the use of variables is that it will create naming 
conflicts with variables
that authors want to create when we *do* add the xforms:variable construct 
to XForms.

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>

Now, let's look at the identified binds created by this.

Hmmm.  I don't know whether to nest the binds for things like name into 
the address and billto binds, 
but either way I seem to have to create duplicate IDs!

This is problematic because we need to be able to convert Forms Tiny into 
Canonical XForms.
It is also problematic because duplicate IDs implies duplicate variables, 
which are not allowed
in XPath.

4) Notice in problem #3 that I did not even have to touch a repeating 
construct to break the system. 
But the real problem is that we need to be able to solve the repeat 
problem in Forms Tiny.  My prior 
post contained a completely working purchase order written in a proposed 
variant of Forms Tiny. 
In order to make the "identified binds+variables" proposal viable you need 
to be able to show how 
that purchase order form (the simplest of repetitions) can be expressed so 
that we can evaluate
its authoring ease relative to the direct "name-to-data" proposal and so 
we can evaluate whether
it transforms into a canonical XForm. 

5) The X of AJAX is for XML!  Preaching to the converted, I know, but the 
attention to AJAX right
now is based on a property of XForms submission: You can exchange XML with 
the server.
Given that the "name-to-data" proposal is capable of effortlessly implying 
structured XML, 
it would be a mistake to adopt another proposal that makes it difficult or 
impossible to let 
authors scale up smoothly to using the Forms Tiny XML data model with 
XForms submissions.
For that matter, we need a system that allows authors to access the Forms 
Tiny data model
period.  In other words, there has to be a few steps along the way between 
Forms Tiny and 
canonical XForms.  Those steps should include:

a) allowing script authors access to the DOM suggested by the Forms Tiny 
model

b) allowing author to take control of the XML instance at a time of their 
choosing to better control
prepopulation results e.g. via JSP.  In other words, let them specify the 
instance.

c) allowing author to take control of submission to do instance 
replacement submissions as
well as switching from urlencoded-post to XML data post

d) allow authors to use XForms actions against the data model in a 
straightforward way to
insert and delete nodes as well as set values.

e) The ultimate in flexibility would be to allow authors the ability to 
add secondary instances 
for temporary variables, and to then add binds or use actions to 
manipulate that data and
to move data between those instances and the primary instance generated by 
FormsTiny.

This would be ideal for adding the ability to talk to a SOAP service to a 
Forms Tiny asset 
without converting it to canonical XForm.

f) Next thing you know the form author has learned everything they need to 
know to write
canonical XForms so their next project can start with a schema and a real 
data model. 

To conclude, there is nothing that you state below Mark as an advantage of 
the "identified
binds + variables" proposal that is not also an advantage the 
"name-to-data" proposal. 
However, the name-to-data proposal has the advantages of  solving all of 
the problems above
with *no* changes other than a simple attribute for #1.  By comparison, 
the "identified
binds + variables" proposal has no answers for the above AND requires the 
addition to
XForms of features like a bind function or variables that refer to bind 
nodesets that require an
extensive overhaul of the XForms processing model to fully specify.  You 
can make them
work in limited use cases, but the language falls apart when the features 
are fully considered.

Best regards,
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





"Mark Birbeck" <mark.birbeck@x-port.net> 
Sent by: www-forms-request@w3.org
10/26/2006 04:56 AM
Please respond to
mark.birbeck@x-port.net


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







Hi Francisco,

> what about
>
> <bind id="A" nodeset="whoKnowsA" />
> <bind id="B" nodeset="whoKnowsB" />
> <bind id="C" nodeset="whoKnowsC" 
calculate="power(id(A)*id(A)+id(B)*id(B), 0.5)"/>

Nice thinking! It's much the same principle as my idea:

  <bind id="C" nodeset="whoKnowsC" calculate="power($A*$A+$B*$B, 0.5)"/>

Either way we get a 'flat space', much like that in HTML forms (or 
HForms).

All I've done in my proposal is to say that since in XForms a bind
statement with an @id creates a named nodeset, why not just say that
the named nodeset is an XPath variable? There's a general feeling that
we'd like to introduce XPath variables at some point anyway, and this
seems a pretty intuitive way of doing it.

Also, there has been enthusiasm in the past ;) for a 'bind' function,
which would allow authors to get at the nodesets created by bind
statement. By making named nodesets into XPath variables there would
no longer be a need for such a function.

In short, what I'm proposing is that we add a feature to XForms that
we could do with anyway (that named nodesets are XPath variables), and
this feature would find a lot of use, not just in HForms. By adding
this feature we ensure that the syntax for HForms is no different to
that of full XForms. This is important since there have been
suggestions that any extensions made to HTML forms to 'beef them up',
would still require some kind of XSLT transformation if the author
needs more power (i.e., XForms). This is counter-productive for an
enormous number of reasons, and with the XPath variable proposal, I'm
hoping that it's unnecessary.

Regards,

Mark

-- 
Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
http://www.formsPlayer.com/