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

Received on Wednesday, 25 October 2006 19:18:32 UTC