Re: forms-lite and data models

Hi Mark,

Notwithstanding Forms Tiny, the need for dot-dot in calculates and such is 
a pain already for XForms, and Forms Tiny doesn't fix that.  So, to me, 
mipcontext a good thing, not a last resort.

However, I believe we found a problem with the flat space bind idea at the 
last face to face, so I thought we already chose not to go in that 
direction.  I believe the problem was that it broke down when you tried to 
do calculate, though it is nice up to that point.

To be concrete, how would the bind idea work if you have, say,

<input name="A" ...
<input name="B" ...
<input name="C"  calculate="power(A*A+B*B, 0.5)" ...

This simple case seems to break because the calculate contains an XPath, 
so things like "A" and "B" match nodes, not the nodesets of binds with the 
matching IDs.

Is it true that your bind idea would produce this result?

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

If so, the clearly the calculate doesn't work.

On a separate matter, I don't see any reason why Forms Tiny (aka HForms) 
should support some or all of XForms submission.  The goal is for us to be 
as smoothly transitional up to full XForms as we can.  There's going to 
come a point when the author will realize "Hey, I want to take control of 
the instance|submission|model that is currently being generated 
automatically for me."  In particular for submission, the form tag could 
imply a particular final submission of the form data, but it should be 
possible, at the authors convenience to add their own submission element 
as a child of the form tag and then call upon that submission rather than 
the default one implied by the form tag.

And, yes, AJAX would be the implementation vehicle.  And yes, this would 
end up meaning that forms authors could expect to be able to easily 
migrate upwards from urlencoded-post to XML-based post by simply adding a 
submission.

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





"Mark Birbeck" <mark.birbeck@x-port.net> 
Sent by: www-forms-request@w3.org
10/25/2006 12:18 PM
Please respond to
mark.birbeck@x-port.net


To
www-forms@w3.org
cc
www-forms-request@w3.org
Subject
Re: forms-lite and data models







Hi John,

I think @mipcontext should really be seen as a last resort, not a
first. I don't think it's a good idea to have too many ways for
evaluation context to be worked out.

I proposed using bindings since it provides a 'flat space' in exactly
the same way that HForms does. XForms provides two ways to address
data--via XPath expressions and via a mapping (what we've called
'bindings'). It seems to me that trying to 'hide' the fact that we are
using XPath is fraught with problems, and a more productive avenue of
exploration would be to see how we can map the HForms 'flat space' to
the XForms 'flat space'.

I should also say that in most of the work we do, we use bindings in
preference to XPath expressions anyway. That way, if the underlying
data has to change, you only need to alter  the XPath expression used
in the bindings, and not expressions used all over the place in
controls. In talking to other XForms developers it's clear that this
is not uncommon, and it means that in the evolution of our archetype,
the forms developer, as they move from HForms to the full power of
XForms, they don't necessarily have to jump straight to using @ref or
@nodeset. Instead their path could take them via bindings.

(An author doesn't necessarily need to get into the full power of
XPath expressions until the name of the bind statement does not match
the underlying XPath expression--which only happens when you need to
use XML.)

Now, since HForms does not support XML submission anyway, there is
little need for hierarchy at the foothills of XForms; why shouldn't we
say that an HForms developer who wants to do an HTTP GET can quite
happily do this:

  <form>
    <input name="quantity" datatype="number" title="number purchased"/>
  </form>

but the HForms developer who is beginning their journey to
XForms--perhaps they are an Ajax developer fed up with changing
libraries each week ;) --has to do this:

  <xf:instance ... />

  <form>
    <input ref="item/quantity" datatype="number" title="number 
purchased"/>
  </form>

The extra mark-up is needed anyway to create the XML, and some mark-up
is needed anyway to identify which part of the XML you want to refer
to; it seems to break with the spirit of HTML to try to do this via
@name. (Adding new attributes is one thing, but changing the meaning
of the content of existing attributes is another.)

As this example shows, by *not* making @name synonymous with @ref we
simply require the use of @ref when we want XPath...but that makes
things far more consistent with the well-established vision of XForms
as it looks when imported into other languages; @ref on 'h:input' is
now no different to putting @ref on 'h:div', on 'xf:range' or on
'svg:rect'.

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/

On 25/10/06, John Boyer <boyerj@ca.ibm.com> wrote:
>
> Hi Dave,
>
> It's very hard to imagine web developers getting confused over the use 
of slash given the analogy to the
> hierarchy to which they are accustomed to seeing when constructing URLs 
and given the direct correlation
> to the hierarchy they are creating within the document itself.
>
> It seems especially unconfusing in the light of the significant number 
of doodads present in CSS1 for
> addressing hierarchies in selectors.
>
> We need a way to create a smooth transition upward toward XForms, and 
that really needs to include
> at least some recognition of hierarchy via the slash so that the author 
does not totally get wigged out
> by the need for complete rewriting of their form app as they go from 
Forms Tiny to XForms.
>
> However, the sincere desire to recognize the data hierarchy that mirrors 
the UI hierarchy does not
> conflict at all with the desire to have a second order eval() function.
>
> In terms of modifications created in a Forms 1.2 to support Forms Tiny, 
I would think that the
> mipcontext attribute is strictly required because the ".." business 
directly contradicts our goals
> of authoring simplicity.  I wouldn't put eval() quite into that 
category, but it is of such a high value
> and so easy to implement, that it would be hard to avoid putting it in 
scope.
>
> 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