What's in XMLForm 1.1? Call for discussion.

[ivelin <iv...@apache.org>]

It is time to start work on the next version.
Primary goal will be compliance with the XForms CR syntax.
A topic which calls for a debate is what, if any, other XForms features in
addition to form controls should be added to XMLForm without sacrificing
performance. Triggers, computations and validation are possible candidates.
What do you think?


-=Ivelin=-

Re: What's in XMLForm 1.1? Call for discussion.

[ivelin <iv...@apache.org>]

> Somehting I would like to see:
>
> * Implementation of all the XForms functions (that are then available
> using jxpath)
>
> http://www.w3.org/TR/xforms/slice7.html#expr-lib

Do you mean the XForms functions that are an addition to the XPath
functions?
Most of them seem relatively easy to implement as JXPath add-ons.
Are you willing to help?

>
> * instance element and instance function to declare more instances, not
> only the Form.getModel( ), especially referenced models would be great:
>
> <xforms:model>
>    <xforms:instance href="http://www.example.com/OrderFormData.xml"/>
> </xforms:model>
>
> all xforms:instance must have an @id tag - the default instance would be
> the the Form.getModel( ).

I am not sure that I understand this request.
There can be multiple forms associated with the current request, session or
application at any point of time.
Form.lookup( HttpRequest request, String formID )
is the method to use when looking for the form instance with a particular
id.
Multiple forms can be also used in a single document as long as they do not
overlap.
The xf:form tag enforces this rule.
This is due to the inherent nature of most client side form implementations
today.
Although XForms allows mixing form controls, this doesn't seem feasible for
a server side implementation.

>
> * binding and calculating:
>
> <xforms:model>
>
>   <xforms:bind ref="/OrderInfo/PriceInfo/TaxRate"
>         calculate="/OrderInfo/TaxInfo/CT * 10"
>         relevant="/OrderInfo/PersonalInfo/Address/State = 'CT'"/>
>
> </xforms:model>
>
> It is somewhat tricky to implement, when the model is on the server and
> the controls are "far away", as updates are expensive, but I could
> imagine the transformer could check whether a bind element is
> "ref"erenced by any control.
>
> Then the transformer could track, which controls could trigger a
> recalculation, so that you can effectively recalculate only the controls
> that need to get updated. [possibly using javascript on the browser
> side, or form submits for browser not supporting javascript].
>
>  bind@ref -> { controls | control needs update }
>  bind@calculate -> { controls | control that trigger updates }

Interestingly enough, this request has come up many times before on this
forum.
Also Struts has a pending JavaScript validation task for almost 2 years now.
Apparently the problems is bigger than it seems, because there are no
popular implementations out there today. A few JavaScript implementations
(like Mozquito and XPE) that were advertised in the recent past are in a RIP
state today.

>
> Additionally, given that some browser already support SOAP (ie, mozilla
> xmlextras) it would be interesting to use a data channel for
> updating/reevalutation of the model. (scratchpad...)

IE 6 also supports similar functionality.
I am thinking that this is probably something beyond the scope of XMLForm,
because it will mean that we have to drop support for older and
non-mainstream browsers.

>
>
> In my current projects I use xsp for the views, to reference other data
> and generic javascript functions to calculate dependent data. You can do
> this quite generically, with javascript hashes and lists and the real
> great Event listener system of the dom. So, in my opinion, a generic
> implementation that conforms to the xforms spec would be feasible.


Chiba has made an impresive progress over the last year.
Maybe it satisfies most of your requests and maybe after all it will be
better if Cococon switches to Chiba in case that's what most people are
looking for.
Chiba is certainly way ahead of XMLForm in its XForms compliance.
The strategic goal of using SAX vs DOM for transformation is violated,
but this may not be such a bad thing with the performance and memory that
the modern servers supply.
While XMLForm counts on the success of Struts and choses to follow the
evolution into pure XML/XSLT web apps, Chiba is an all out server side
XForms implementation.
Anyway, this is something to think and talk about.


Ivelin

Re: What's in XMLForm 1.1? Call for discussion.

[Jakob Praher <jp...@yahoo.de>]

Am Mon, 2003-03-31 um 05.52 schrieb ivelin:
> It is time to start work on the next version.
> Primary goal will be compliance with the XForms CR syntax.
very good.

> A topic which calls for a debate is what, if any, other XForms features in
> addition to form controls should be added to XMLForm without sacrificing
> performance. Triggers, computations and validation are possible candidates.
> What do you think?
> 

Somehting I would like to see:

* Implementation of all the XForms functions (that are then available
using jxpath)

	http://www.w3.org/TR/xforms/slice7.html#expr-lib

* instance element and instance function to declare more instances, not
only the Form.getModel( ), especially referenced models would be great:

<xforms:model>
   <xforms:instance href="http://www.example.com/OrderFormData.xml"/>
</xforms:model>

all xforms:instance must have an @id tag - the default instance would be
the the Form.getModel( ).

* binding and calculating:

<xforms:model>

  <xforms:bind ref="/OrderInfo/PriceInfo/TaxRate"
        calculate="/OrderInfo/TaxInfo/CT * 10"
        relevant="/OrderInfo/PersonalInfo/Address/State = 'CT'"/>

</xforms:model>

It is somewhat tricky to implement, when the model is on the server and
the controls are "far away", as updates are expensive, but I could
imagine the transformer could check whether a bind element is
"ref"erenced by any control.

Then the transformer could track, which controls could trigger a
recalculation, so that you can effectively recalculate only the controls
that need to get updated. [possibly using javascript on the browser
side, or form submits for browser not supporting javascript].

 bind@ref -> { controls | control needs update }
 bind@calculate -> { controls | control that trigger updates }

Additionally, given that some browser already support SOAP (ie, mozilla
xmlextras) it would be interesting to use a data channel for
updating/reevalutation of the model. (scratchpad...)


In my current projects I use xsp for the views, to reference other data
and generic javascript functions to calculate dependent data. You can do
this quite generically, with javascript hashes and lists and the real
great Event listener system of the dom. So, in my opinion, a generic
implementation that conforms to the xforms spec would be feasible.


-- Jakob