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/

Received on Thursday, 26 October 2006 12:02:26 UTC