RE: forms-lite and data models

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)"/>
 
 
 
Kind Regards
Francisco
 
facileXForms - Really AJAX at heart
 

  _____  

From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On Behalf
Of John Boyer
Sent: 26 October 2006 00:19
To: mark.birbeck@x-port.net
Cc: www-forms@w3.org; www-forms-request@w3.org
Subject: 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